JDownloader 2 Save.TV APIv3 BETATest

Top-Downloadmanager mit voller Save.TV Integration! (automatische Archivübernahme u.v.a.m.)
Benutzeravatar
jdownloader_pspzockerscene
Beiträge: 90
Registriert: Mo 28. Mär 2016, 18:28
bevorzugter Onlinevideorecorder: Keinen
Kontaktdaten:

JDownloader 2 Save.TV APIv3 BETATest

Beitrag von jdownloader_pspzockerscene » 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 8-)
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.
Zuletzt geändert von Fredel am Fr 11. Aug 2017, 21:35, insgesamt 1-mal geändert.
Grund: Überschrift & auf Globale Bekanntmachung geändert


Offizielle JDownloader Webseite:
http://jdownloader.org/
Offizielles JDownloader Supportforum:
https://board.jdownloader.org/

Link:
BBcode:
HTML:
Hide post links
Show post links

Fredel
Beiträge: 705
Registriert: So 21. Feb 2016, 20:45
bevorzugter Onlinevideorecorder: Save.TV

JDownloader 2 Save.TV APIv3 BETATest

Beitrag von Fredel » Fr 11. Aug 2017, 21:54

jdownloader_pspzockerscene hat geschrieben:
Fr 11. Aug 2017, 16:18
@Mods
Wäre vielleicht sinnvoll, diesen Beitrag anzupinnen.
erledigt
jdownloader_pspzockerscene hat geschrieben:
Fr 11. Aug 2017, 16:18
Also wer Interesse hat kann mit Testen und Bugs melden ;)
Gerne. Updates am JDL durchgeführt. Wo kann man die Beta Phase/Api aktivieren, die Felder die ich hierfür vermute sind ausgegraut? Oder sind die Plugin-Updates nur noch nicht verbreitet?
170811_TV-Forum-JDownloader_Save.TV_Apiv3-Beta.jpg
170811_TV-Forum-JDownloader_Save.TV_Apiv3-Beta.jpg (20.83 KiB) 339 mal betrachtet
jDownloader & Save.TV: 1. Schritte - automatischer Download <--> Save.TV Manager Version 3 Update: Favoriten retten

Link:
BBcode:
HTML:
Hide post links
Show post links

Benutzeravatar
jdownloader_pspzockerscene
Beiträge: 90
Registriert: Mo 28. Mär 2016, 18:28
bevorzugter Onlinevideorecorder: Keinen
Kontaktdaten:

JDownloader 2 Save.TV APIv3 BETATest

Beitrag von jdownloader_pspzockerscene » Fr 11. Aug 2017, 21:57

Danke :)
Also aktuell gibt es keine testbaren "BETA Features", hatte diese Option mal eingebaut und bisher nie gebraucht.

Sobald die API eingebaut ist wird man das API Häckchen wieder aktivieren können.

Weitere Infos folgen, bin heute fast fertig geworden :)

Grüße, psp
Offizielle JDownloader Webseite:
http://jdownloader.org/
Offizielles JDownloader Supportforum:
https://board.jdownloader.org/

Link:
BBcode:
HTML:
Hide post links
Show post links

Benutzeravatar
jdownloader_pspzockerscene
Beiträge: 90
Registriert: Mo 28. Mär 2016, 18:28
bevorzugter Onlinevideorecorder: Keinen
Kontaktdaten:

JDownloader 2 Save.TV APIv3 BETATest

Beitrag von jdownloader_pspzockerscene » Do 17. Aug 2017, 04:47

Das Update kommt, sobald ich genug Zeit zum aktiven Support habe.
Hier ist zwar alles fertig, aber es jetzt zu releasen bringt nichts, wenn ich keine Zeit für Support & Bugfixes habe.
Bringt ja nichts, euch die eventuell fehlerhafte Version zu geben und euch mit eventuellen Problemen erstmal ne Woche alleine zu lassen.

Muss es selbst noch testen und Zeit haben, dann kommt das Update ;)

Grüße, psp
Offizielle JDownloader Webseite:
http://jdownloader.org/
Offizielles JDownloader Supportforum:
https://board.jdownloader.org/

Link:
BBcode:
HTML:
Hide post links
Show post links

Dieter Haag
Beiträge: 125
Registriert: Sa 12. Mär 2016, 23:57

JDownloader 2 Save.TV APIv3 BETATest

Beitrag von Dieter Haag » Do 17. Aug 2017, 11:38

Der JDownloader startet seit heute nicht mehr. Fehlermeldung:
An error has occured during setup
java lang class Not Found Exception orgjdownloader update launcher.Jdownloader
(und 7 weitere Zeilen

Link:
BBcode:
HTML:
Hide post links
Show post links

Fredel
Beiträge: 705
Registriert: So 21. Feb 2016, 20:45
bevorzugter Onlinevideorecorder: Save.TV

JDownloader 2 Save.TV APIv3 BETATest

Beitrag von Fredel » Do 17. Aug 2017, 14:09

Dieter Haag hat geschrieben:
Do 17. Aug 2017, 11:38
[...]java lang class Not Found Exception orgjdownloader update launcher.Jdownloader
Ev. hat Dein Virenscanner eine Datei wärend der Installation entfernt. Das sollte in dessen Log-Files auch ersichtlich sein. Ja nach Programm kann man darüber, oder über Einstellungen, eine Ausnahme eintragen. Dann einfach eine neue Installation vornehmen.

Offiziellen Support vom JDL Team gibt es übrigens am besten in deren Forum.
jDownloader & Save.TV: 1. Schritte - automatischer Download <--> Save.TV Manager Version 3 Update: Favoriten retten

Link:
BBcode:
HTML:
Hide post links
Show post links

thomasfl
STV MANAGER
STV MANAGER
Beiträge: 300
Registriert: Fr 4. Mär 2016, 11:54

JDownloader 2 Save.TV APIv3 BETATest

Beitrag von thomasfl » Do 17. Aug 2017, 21:10

jdownloader_pspzockerscene hat geschrieben:
Fr 11. Aug 2017, 16:18
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.
In der /get/v3/telecasts Abfrage gibt es das Feld existsRecord, die Abfrage checkt hier aber nur, ob der Telecast zur Aufnahme markiert ist/war. Theoretisch wäre es sicher machbar, hier auch gleich noch einen Records Array einzubinden, der alle ggfs verfügbaren Aufnahmen übergibt. Save.Tv hat es halt andersherum gelöst, jeder Record enthält auch seinen zugehörigen Telecast.
jdownloader_pspzockerscene hat geschrieben:
Fr 11. Aug 2017, 16:18
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 denke, die Files werden erst mit der /get/v3/records/{id}/downloads/{recordformat} Abfrage überhaupt aus dem Datenstrom erzeugt. Dementsprechend steht die Dateigröße auch nicht vorher zur Verfügung. Musst Du also entweder die Abfrage zweimal machen, oder weiter schätzen ...

Insgesamt sind die Abfragen aber in der Regel so schnell, dass man halt mehrere losjagen kann. ;)
Bild STV MANAGER - Tool zur Verwaltung von Save.TV --- Neuigkeiten & Downloads --- Fragen & Support

Link:
BBcode:
HTML:
Hide post links
Show post links

Benutzeravatar
jdownloader_pspzockerscene
Beiträge: 90
Registriert: Mo 28. Mär 2016, 18:28
bevorzugter Onlinevideorecorder: Keinen
Kontaktdaten:

JDownloader 2 Save.TV APIv3 BETATest

Beitrag von jdownloader_pspzockerscene » Di 5. Sep 2017, 23:17

thomasfl hat geschrieben:
Do 17. Aug 2017, 21:10

Ich denke, die Files werden erst mit der /get/v3/records/{id}/downloads/{recordformat} Abfrage überhaupt aus dem Datenstrom erzeugt. Dementsprechend steht die Dateigröße auch nicht vorher zur Verfügung. Musst Du also entweder die Abfrage zweimal machen, oder weiter schätzen ...

Insgesamt sind die Abfragen aber in der Regel so schnell, dass man halt mehrere losjagen kann. ;)
Ich glaube nicht, dass die Dateien erst bei dieser Anfrage erzeugt werden - die Dateigröße könnte man sicher auch davor ausgeben.
Ist allerdings nicht so tragisch - schätzen geht ganz gut und mehr Requests mag ich auch nicht - wenn man viele Links einfügt und diese manuell geprüft werden (also bei Stv selten, da man vermutlich meist das komplette Archiv hinzufügt) merkt man das durchaus.

Das neue Plugin wird erst nach dem 17.09.2017 released werden, da ich aktuell sehr beschäftigt bin und keinen schnellen Support geben könnte
--> Ein verbuggter Release wäre sehr dumm!

Danke für den "existsRecord" Tipp, aber da ich dafür erst /telecast anfragen müsste macht dies wenig sinn.
Wie bereits geschrieben werden die meisten vom User eingefügten IDs online- UND abgeschlossene Aufnahmen sein daher sollte die Abfragereihenfolge record --> ggf. telecast passen.

Der Crawler wird auch noch um einiges verschnellert, da man über die API nun gut filtern kann und somit nicht alle Daten holen muss nur um dann im Plugin zu filtern, welche Aufnahmen von welchem Datum der User nun möchte.

Grüße, psp
Zuletzt geändert von jdownloader_pspzockerscene am Do 7. Sep 2017, 15:50, insgesamt 1-mal geändert.
Offizielle JDownloader Webseite:
http://jdownloader.org/
Offizielles JDownloader Supportforum:
https://board.jdownloader.org/

Link:
BBcode:
HTML:
Hide post links
Show post links

Benutzeravatar
Fox   
Administrator
Beiträge: 565
Registriert: Do 3. Mär 2016, 13:29
bevorzugter Onlinevideorecorder: SaveTV
Kontaktdaten:

JDownloader 2 Save.TV APIv3 BETATest

Beitrag von Fox    » Mi 6. Sep 2017, 16:11

Das ist sehr erfreulich zu hören. Ich denke, dass sich auch SaveTV freuen wird, wenn der JD2 die API verwendet, das dürfte dort die Datenbankserver durch zielgerichtetere Anfragen entlasten. Man könnte sich auch überlegen die APIv3 als Default einzusetzen, anstelle der Webseite.

RecordID vs TelecastID
So wie ich die Welt nun sehe hat man über die SaveTV-Webseite nie das wirklich Datenbank-Eigenleben bei SaveTV kennengelernt und entsprechend nur mit TelecastIDs gearbeitet. Durch die SaveTV-API lernt man allerdings nun ein wenig vom Innenleben kennen,
  • TelecastID - Ein Eintrag im EPG
  • RecordID - Eine programmierte TV-Aufnahme (ggf. fertiggestellt oder in der Zukunft liegend)
Für den jDownloader dürften dementsprechend ausschließlich die RecordIDs relevant sein. Alles was passieren könnte wäre, dass ein EPG-Eintrag (TelecastID) programmiert wird, und dadurch in der Zukunft auch ein RecordID-Eintrag entsteht. Für mich würde es allerdings keinen Sinn Ergeben, in die Downloadliste eines Downloadmanagers eine Datei (TelecastID) aufzunehmen, von der nicht einmal sich ist, dass sie angelegt werden wird. Bei einer RecordID ist zumindest garantiert, dass die Sendung programmiert wurde und - sofern sie nicht gelöscht wird - nach der Ausstrahlung heruntergeladen werden kann.

Aufnahmegröße
Die Werte zur Dateigröße von GET /v3/records/{id}/downloads/{recordformat} sowie GET /v3/records/{id} der API sind geschätzt. Diese Werte stimmen nicht mit der tatsächlichen Dateigröße überein - zumindest haben die Dateien die ich heruntergeladen habe immer ein wenig abweichende Dateigrößen gehabt. Auf diese weiße muss der JD2 allerdings nicht mehr selbst schätzen, sondern die API übernimmt die Aufgabe offenbar nun. Das hat zumindest den Vorteil, dass man in Zukunft nicht mehr etwas am JD-Plug-in ändern muss, wenn SaveTV die Bitraten verändert.
Erkennen - Verstehen - Nutzen
Es gibt immer schlechte Beispiele - aber sollte man nicht versuchen, besser zu sein?

Link:
BBcode:
HTML:
Hide post links
Show post links

Benutzeravatar
sv00010
Beiträge: 289
Registriert: Sa 20. Feb 2016, 16:41
bevorzugter Onlinevideorecorder: onlinetvrecorder.com
Kontaktdaten:

JDownloader 2 Save.TV APIv3 BETATest

Beitrag von sv00010 » Mi 6. Sep 2017, 20:41

Fox    hat geschrieben:
Mi 6. Sep 2017, 16:11
Die Werte zur Dateigröße von GET /v3/records/{id}/downloads/{recordformat} sowie GET /v3/records/{id} der API sind geschätzt. Diese Werte stimmen nicht mit der tatsächlichen Dateigröße überein - zumindest haben die Dateien die ich heruntergeladen habe immer ein wenig abweichende Dateigrößen gehabt.
Das war bei der API Version 2 auch schon so.
Erst die Download-Anforderung hat die wirkliche Größe verfügbar gemacht.

Link:
BBcode:
HTML:
Hide post links
Show post links

Antworten

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast