JDownloader 2 Save.TV APIv3 BETATest
Verfasst: Fr 11. Aug 2017, 16:18
Hey Leute,
diesmal zuerst über euer Forum und dann in unserem.
Ich arbeite aktuell an der Implementation der Stv APIv3 in JDownloader.
Lange ists her, seitdem wir die Möglichkeit haben, die API zu nutzen (ca 1 Jahr meine ich) - also wird das nun endlich umgesetzt
Das und viele viele viele weitere Verbesserungen könnt ihr in nächster Zeit erwarten.
Da ich als Nutzer weiß wie nervig zwangsläufige Änderungen sind läuft das ganze in 2 Schritten ab:
1. Release vom Update - ab jetzt kann jeder freiwillig auf die API umstellen und Fehler melden.
Da auch der Code zum Zugriff der Webseite per Plugin umgeschrieben werden musste, sind neue Bugs auch hier möglich, jedoch unwahrscheinlicher als per API Nutzung.
Also wer Interesse hat kann mit Testen und Bugs melden
2. Sobald die APIv3 Implementation einigermaßen stabil läuft, wird auf diese zwangsläufig umgestellt.
Zunächst wird man noch auf die Webseite umstellen können; diese Option wird dann irgendwann entfernt, da sie nach der nächsten Webseitenänderung sowieso kaputtgehen würde.
Ansonsten da mir der Stv Support bisher nie geantwortet hat, ich aber weiß, dass hier im Forum mitgelesen wird; das ist an euch:
API Störfaktoren / Fragen:
Die neue API hat bisher nur wenige Dinge, die mich stören:
1. Ablaufdatum oder weitere Informationen zum Account kann man nicht abrufen (Preis usw [auch wenn das zB eh unwichtig ist]) ... oder ich habe einfach nicht verstanden, über welchen Aufruf man diese bekommen kann.
Was spricht dagegen, zumindest das Ablaufdatum des Accounts zur Verfügung zu stellen?
Bitte erhört meine Gebete ... und baut das einfach in den "/v3/user" Aufruf ein.
Sowas wie "contract.expiredate" oder "contract.nextpaymentdate", das in Form eines Timestamps oder Datums diese Information zurückgibt.
2. Was etwas nervig ist: Es wird quasi unterschieden zwischen telecastID und recordID:
Wenn ich jetzt z.B. 12345678 habe und die noch nicht aufgenommen ist gibt es die nur als telecastID und nicht als Record d.h. wenn ich nun ne v3/records Anfrage mache wird nichts gefunden.
Also mache ich eine v3/telecasts Anfrage, weil ich zumindest im Anwendungsfall JDownloader einfach wissen möchte, was sich hinter der ID verbirgt - und noch dazu kann ich davor nicht zu 100% wissen, ob die ID bereits aufgenommen wurde oder nicht.
Allerdings bekomme ich bei einer v3/telecasts Anfrage keine Infos zu Dateigrößen, werbefrei usw usw und die sind ganz gut zu haben.
Da man aber davon ausgehen kann, dass 99,99% aller eingefügten telecastIDs bereits aufgenommen- und ladbar sind mache ich erst die /records Anfrage --> Falls Objekt nicht gefunden die /telecasts Anfrage --> Falls hier auch offline, existiert die Datei nicht
So wie ich es aktuell handhabe passt das auch nur falls ihr lust habt nachzubessern, hier meine Vorschläge:
- Legt die v3/telecasts und v3/records Anfragen zusammen und gebt halt einfach in einer Anfrage alle Infos zurück.
oder
- Macht noch einen zusätzlichen Aufruf bei dem es egal ist, ob die ID aufgenommen wurde oder nicht - gebt einfach alle Infos zu dieser ID zurück.
So braucht man nicht 2 Anfragen um festzustellen, ob es die ID überhaupt gibt.
3. Es gibt keine Möglichkeit, einfach an alle Dateigrößen aller telecastIDs zu kommen.
Gerade wenn man JD verwendet ist es schön, diese zu sehen und ich verstehe euer Problem nicht.
Wenn man per '/records/bla/downloads' eine Aufnahme herunterladen will bekommt man letztendlich "estimatedFileSize" --> Aber was will ich damit, ich starte gerade den Download da bekomme ich die Dateigröße sowieso.
Packt das doch einfach zu den "formats" Informationen.
So wie es aktuell aussieht habt ihr nur eine "ungefähre" Dateigröße verfügbar, die der echten aber zumindest näher kommt als die, die unser Plugin schätzt.
Ich bitte euch trotzdem darum, geplante Webseitenänderungen noch nicht vor dem vollständigen Umzug auf eure API durchzuführen - das führt nur zu Ausfällen
Den aktuellen Status der Implementation könnt ihr in folgendem Ticket einsehen:
https://svn.jdownloader.org/issues/84058
@Mods
Wäre vielleicht sinnvoll, diesen Beitrag anzupinnen.
Grüße, pspzockerscene
P.S. Wer Rechtschreibfehler findet, darf diese behalten.
diesmal zuerst über euer Forum und dann in unserem.
Ich arbeite aktuell an der Implementation der Stv APIv3 in JDownloader.
Lange ists her, seitdem wir die Möglichkeit haben, die API zu nutzen (ca 1 Jahr meine ich) - also wird das nun endlich umgesetzt
Das und viele viele viele weitere Verbesserungen könnt ihr in nächster Zeit erwarten.
Da ich als Nutzer weiß wie nervig zwangsläufige Änderungen sind läuft das ganze in 2 Schritten ab:
1. Release vom Update - ab jetzt kann jeder freiwillig auf die API umstellen und Fehler melden.
Da auch der Code zum Zugriff der Webseite per Plugin umgeschrieben werden musste, sind neue Bugs auch hier möglich, jedoch unwahrscheinlicher als per API Nutzung.
Also wer Interesse hat kann mit Testen und Bugs melden
2. Sobald die APIv3 Implementation einigermaßen stabil läuft, wird auf diese zwangsläufig umgestellt.
Zunächst wird man noch auf die Webseite umstellen können; diese Option wird dann irgendwann entfernt, da sie nach der nächsten Webseitenänderung sowieso kaputtgehen würde.
Ansonsten da mir der Stv Support bisher nie geantwortet hat, ich aber weiß, dass hier im Forum mitgelesen wird; das ist an euch:
API Störfaktoren / Fragen:
Die neue API hat bisher nur wenige Dinge, die mich stören:
1. Ablaufdatum oder weitere Informationen zum Account kann man nicht abrufen (Preis usw [auch wenn das zB eh unwichtig ist]) ... oder ich habe einfach nicht verstanden, über welchen Aufruf man diese bekommen kann.
Was spricht dagegen, zumindest das Ablaufdatum des Accounts zur Verfügung zu stellen?
Bitte erhört meine Gebete ... und baut das einfach in den "/v3/user" Aufruf ein.
Sowas wie "contract.expiredate" oder "contract.nextpaymentdate", das in Form eines Timestamps oder Datums diese Information zurückgibt.
2. Was etwas nervig ist: Es wird quasi unterschieden zwischen telecastID und recordID:
Wenn ich jetzt z.B. 12345678 habe und die noch nicht aufgenommen ist gibt es die nur als telecastID und nicht als Record d.h. wenn ich nun ne v3/records Anfrage mache wird nichts gefunden.
Also mache ich eine v3/telecasts Anfrage, weil ich zumindest im Anwendungsfall JDownloader einfach wissen möchte, was sich hinter der ID verbirgt - und noch dazu kann ich davor nicht zu 100% wissen, ob die ID bereits aufgenommen wurde oder nicht.
Allerdings bekomme ich bei einer v3/telecasts Anfrage keine Infos zu Dateigrößen, werbefrei usw usw und die sind ganz gut zu haben.
Da man aber davon ausgehen kann, dass 99,99% aller eingefügten telecastIDs bereits aufgenommen- und ladbar sind mache ich erst die /records Anfrage --> Falls Objekt nicht gefunden die /telecasts Anfrage --> Falls hier auch offline, existiert die Datei nicht
So wie ich es aktuell handhabe passt das auch nur falls ihr lust habt nachzubessern, hier meine Vorschläge:
- Legt die v3/telecasts und v3/records Anfragen zusammen und gebt halt einfach in einer Anfrage alle Infos zurück.
oder
- Macht noch einen zusätzlichen Aufruf bei dem es egal ist, ob die ID aufgenommen wurde oder nicht - gebt einfach alle Infos zu dieser ID zurück.
So braucht man nicht 2 Anfragen um festzustellen, ob es die ID überhaupt gibt.
3. Es gibt keine Möglichkeit, einfach an alle Dateigrößen aller telecastIDs zu kommen.
Gerade wenn man JD verwendet ist es schön, diese zu sehen und ich verstehe euer Problem nicht.
Wenn man per '/records/bla/downloads' eine Aufnahme herunterladen will bekommt man letztendlich "estimatedFileSize" --> Aber was will ich damit, ich starte gerade den Download da bekomme ich die Dateigröße sowieso.
Packt das doch einfach zu den "formats" Informationen.
So wie es aktuell aussieht habt ihr nur eine "ungefähre" Dateigröße verfügbar, die der echten aber zumindest näher kommt als die, die unser Plugin schätzt.
Ich bitte euch trotzdem darum, geplante Webseitenänderungen noch nicht vor dem vollständigen Umzug auf eure API durchzuführen - das führt nur zu Ausfällen
Den aktuellen Status der Implementation könnt ihr in folgendem Ticket einsehen:
https://svn.jdownloader.org/issues/84058
@Mods
Wäre vielleicht sinnvoll, diesen Beitrag anzupinnen.
Grüße, pspzockerscene
P.S. Wer Rechtschreibfehler findet, darf diese behalten.