Partnerbox Remote-Timer encoded sref nicht überall

  • Ich habe z.B. folgenden Sender in meinem Bouquet. Dieser wurde mit Partnerbox angelegt und ich habe lediglich die URL auf die rtsp-Variante geändert:


    Code
    #SERVICE 1:256:19:EF10:421:1:C00000:0:0:0:rtsp%3a//XXXXXX%3XXXXXX@XXXXXX%3a554/stream?ref=1%3a0%3a19%3aEF10%3a421%3a1%3aC00000%3a0%3a0%3a0%3a:RTL HD
    #DESCRIPTION RTL HD

    Legt man auf der Client-Box einen Remote-Timer an, erhält man als Fehlermeldung: 400 Bad Request


    Das journal sieht dann so aus:


    Code
    Feb 07 16:40:25 dm520 enigma2[629]: action ->  SetupActions save
    Feb 07 16:40:25 dm520 enigma2[629]: [Connector] - Running command  http://10.8.0.1:80/web/session
    Feb 07 16:40:25 dm520 enigma2[629]: [Connector] - Read sessionId
    Feb 07 16:40:25 dm520 enigma2[629]: [Partnerbox] - got session
    Feb 07 16:40:25 dm520 enigma2[629]: [Connector] - Running command  http://10.8.0.1:80/web/timeradd?sRef=1:256:19:EF10:421:1:C00000:0:0:0:rtsp%3a//XXXXXX%3aXXXXXX@XXXXXX%3a554/stream?ref=1%3a0%3a19%3aEF10%3a421%3a1%3aC00000%3a0%3a0%3a0%3a:RTL HD&begin=1518015600&end=1518019200&name=Verdachtsf%C3%A4lle&description=Verdachtsf%C3%A4lle&dirname=/media/hdd/movie/&tags=None&eit=3364&justplay=0&afterevent=3&repeated=0
    Feb 07 16:40:26 dm520 enigma2[629]: [Connector] - Error in runCommand [Failure instance: Traceback (failure with no frames): <class 'twisted.web.error.Error'>: 400 Bad Request
    Feb 07 16:40:26 dm520 enigma2[629]: ]
    Feb 07 16:40:26 dm520 enigma2[629]: [Partnerbox] - Error in sendPartnerBoxWebCommand 400 Bad Request
    Feb 07 16:40:26 dm520 enigma2[629]: [Partnerbox] - Error in getSessionId [Failure instance: Traceback (failure with no frames): <class 'twisted.web.error.Error'>: 400 Bad Request
    Feb 07 16:40:26 dm520 enigma2[629]: ]


    Das liegt daran, dass die URL falsch aufgebaut ist ("RTL HD" statt "RTL%20HD").


    Ich habe dann in RemoteTimerEntry.py ein urllib.quote() um die sref gepackt. Danach funktioniert das Anlegen des Timers:


    Code
    Feb 07 17:00:22 dm520 enigma2[562]: action ->  SetupActions save
    Feb 07 17:00:22 dm520 enigma2[562]: [Connector] - Running command  http://10.8.0.1:80/web/session
    Feb 07 17:00:22 dm520 enigma2[562]: [Connector] - Read sessionId
    Feb 07 17:00:22 dm520 enigma2[562]: [Partnerbox] - got session
    Feb 07 17:00:22 dm520 enigma2[562]: [Connector] - Running command  http://10.8.0.1:80/web/timeradd?sRef=1%3A256%3A19%3AEF10%3A421%3A1%3AC00000%3A0%3A0%3A0%3Artsp%253a//XXXXXX%253aXXXXXX%40XXXXXX%253a554/stream%3Fref%3D1%253a0%253a19%253aEF10%253a421%253a1%253aC00000%253a0%253a0%253a0%253a%3ARTL%20HD&begin=1518019200&end=1518021000&name=Betrugsf%C3%A4lle&description=Betrugsf%C3%A4lle&dirname=/media/hdd/movie/&tags=None&eit=3424&justplay=0&afterevent=3&repeated=0
    Feb 07 17:00:23 dm520 enigma2[562]: create buffer for widget 600 x 200


    Ich bekam jedoch auch einen 400 Bad Request beim Versuch die Remote Timer Liste zu öffnen und den angelegten Timer wieder zu löschen. Da wurde dann wieder die sref nicht encoded.



    Ich habe daraufhin alle *.py durchsucht und die entsprechenden Stellen geändert. Patch im Anhang des Posts.




    Client-Box hat original unstable DMM-Image - Serverbox läuft mit NN2

  • Also ich hab soeben auf SRF zwei einen Remote Timer gesetzt und da kommt kein Bad Request. Kannst du mir bitte mal genau beschreiben, was du machst. Also die Schritte.

    Gruss
    Dre


    Boxen (im Einsatz): DM920, DM900, DMOne
    Developer Project Merlin - we are OpenSource

  • Bin nicht an der Box, da unterwegs. Aber ich habe, glaube ich, einfach auf die Info-Taste gedrückt, um zur Sendungsinfo zu gelangen, dort dann auf grün (Timer setzen) und ohne Änderungen vorzunehmen (es war automatisch der Remote-Timer gewählt) den Timer gesetzt.

  • OK, danke. Den Weg hatte ich noch gar nie genutzt. Da krieg ich auch einen Fehler. Aber mehr wegen eines anderen Parameters.

    Gruss
    Dre


    Boxen (im Einsatz): DM920, DM900, DMOne
    Developer Project Merlin - we are OpenSource

  • Muss mich korrigieren. Es klappt bei mir auch über diesen Weg. Hatte eine Endzeit < aktuelle Zeit eingegeben.

    Gruss
    Dre


    Boxen (im Einsatz): DM920, DM900, DMOne
    Developer Project Merlin - we are OpenSource

  • Ich hab mir deinen Patch angeschaut:
    - wenn die ServiceReference aus dem Timer genommen wird, dann ist diese bereits ohne Sendername > kein Problem
    - wenn getServiceRef() aufgerufen wird, dann wird der Name abgeschnitten > kein Problem


    Somit kann ich zumindest mit der regulären Implementierung keinen Bedarf feststellen, die servicereference zu encoden, da es keine Zeichen haben kann, die Probleme machen.


    Dennoch wäre ich froh, wenn du deinen Fall nochmals nachstellen kannst.

    Gruss
    Dre


    Boxen (im Einsatz): DM920, DM900, DMOne
    Developer Project Merlin - we are OpenSource

  • Ich bin frühestens Montag wieder an der Box, um das nachzustellen, kann das dann aber natürlich machen. Was ich Dir aber schon sagen kann: Bei mir wird bei getServiceUrl nichts abgeschnitten, sondern die komplette sref inkl. Url und Name zurück gegeben.


    Wenn an die Server-Box allerdings nur die abgeschnittene Variante übergeben werden soll (was ja eigentlich auch Sinn macht, wenn ich jetzt mal drüber nachdenke - wofür braucht der Server auch die Url :), dann wäre mein Patch am Ende der folgenden Seite ausreichend: Reconnectfunktion bei Bouquet Streams
    Zumindest für den Weg über die Info-Taste.


    Das Problem hatte ich schon, als noch NN2 auf der Client-Box lief und jetzt immernoch mit dem DMM-Image.


    Komisch, dass die sref bei Dir automatisch abgeschnitten wird. Aber zumindest der "split-patch" schadet ja definitiv nicht, wenn Du ihn überall einbaust, wo timerAdd aufgerufen wird. Die anderen Stellen sind ja dann eh unnötig, da die von drr Server-Box ausgelesenen Timer dann keine Sonderzeichen enthalten können.

  • So, habe mir das jetzt nochmal angeschaut, wieder den gleichen Fehler gehabt und dann nochmal getestet. Bei meinen Kanälen wird die sref nicht abgeschnitten. Ich habe dann testweise den Sender nochmal per Plugin eingefügt und den Sendernamen angepasst (Namen der Server-Box entfernt)


    Code
    #SERVICE 1:256:19:88:E:85:C00000:0:0:0:rtsp%3a//XXXXXX%3aXXXXXX@XXXXXX%3a554/stream?ref=1%3a0%3a19%3a88%3aE%3a85%3aC00000%3a0%3a0%3a0%3a:TNT Comedy HD
    #DESCRIPTION TNT Comedy HD


    -> 400 Bad Request, da die an timerAdd übergebene sref sowohl Url, als auch Sendernamen mit Leerzeichen enthält.



    Code
    #SERVICE 1:256:19:88:E:85:C00000:0:0:0:http%3a//XXXXXX%3aXXXXXX@10.8.0.1%3a8001/1%3a256%3a19%3a88%3aE%3a85%3aC00000%3a0%3a0%3a0%3a:TNT Comedy HD
    #DESCRIPTION TNT Comedy HD

    -> Funktioniert ohne Probleme


    Ich kann allerdings - bis auf die Url - keinen Unterschied erkennen. Da meine Client-Box per VPN über das Internet mit meiner Server-Box verbunden ist, reicht die Bandbreite für Variante 2 leider nicht aus - daher benutze ich den rtsp-Server.


    Ich teste mal etwas weiter, warum sich der RemoteTimer mit rtsp-Url anders verhält als mit httpUrl.

  • Ok, Problem gefunden.


    getServiceRef() aus PartnerboxFunctions.py schneidet die sref nur ab, wenn "http" gefunden wurde. Da meine Urls kein "http" enthalten, wird auch nichts abgeschnitten.


    Habe jetzt folgende Lösung bei mir lokal eingebaut:



    Ein Unterschied zwischen den Sendern ist mir allerdings noch aufgefallen:


    Beim http-Sender enthält die Timer-Description den Namen der aktuellen Folge (denke mal die kommt aus der epg description). Beim rtsp-Sender enthält sie den Namen der Serie (ist also gleich dem Titel der Aufnahme). Hast Du eine Ahnung woran das liegen könnte und ob man das einfach beheben kann? Schätze es liegt daran, dass das EPG mit EPGImporter importierte Daten enthält, während über den http-Stream ja auch noch zusätzliche EPG-Daten reinkommen. Sendungs-Info sieht allerdings bei beiden Sendern gleich aus - haben ja auch die gleiche sref und greifen auf die gleichen Einträge in der epg.db zu.


    Edit: Ok, vergiss die Timer-Beschreibungsfrage wieder :smiling_face: Liegt einfach daran, dass das EPG mit EPGImporter importiert wurde. Ich habe mir jetzt nämlich einfach mal die epg.db von meiner Serverbox gezogen. Jetzt wird die Beschreibung auch auf dem rtsp-Kanal richtig gesetzt.

    Einmal editiert, zuletzt von maluhi ()

  • Ich muss das mit getServiceReference mal anschauen. Ich denke, das lässt sich anders lösen. Dann hast du auch kein Problem mehr.

    Gruss
    Dre


    Boxen (im Einsatz): DM920, DM900, DMOne
    Developer Project Merlin - we are OpenSource

  • machs bitte mal so:

    Code
    def getServiceRef(sreference):
    	x = sreference.split(':')
    	del x[x[10] and 11 or 10:]
    	serviceref = ':'.join(x)
    	return serviceref

    Gruss
    Dre


    Boxen (im Einsatz): DM920, DM900, DMOne
    Developer Project Merlin - we are OpenSource

  • Habe ich jetzt mal getestet, mit folgendem Resultat:


    Code
    Feb 13 20:40:28 dm520 enigma2[193]: [Connector] - Running command  http://10.8.0.1:80/web/timeradd?sRef=1:256:19:88:E:85:C00000:0:0:0:rtsp%3a//XXXXX%XXXXX@XXXXX%3a554/stream?ref=1%3a0%3a19%3a88%3aE%3a85%3aC00000%3a0%3a0%3a0%3a&begin=1518550800&end=1518552000&name=Two%20and%20a%20Half%20Men&description=Feuchtfr%C3%B6hliche%20Weihnacht&dirname=/media/hdd/movie/&tags=None&eit=3380&justplay=0&afterevent=3&repeated=0


    Dadurch, dass jetzt kein Sendername mehr enthalten ist, wurde der Timer angelegt.


    Allerdings wird mir die Aufnahme nun in der Remote Timer Liste angezeigt, als wenn der Name des Senders "//XXXXX:XXXXX@XXXXX:544/stream?ref=1:0:...." ist.


    Es kommt nämlich von timerlist folgende Rückgabe:



    XML
    <?xml version="1.0" encoding="UTF-8"?>
    <e2timerlist>
            <e2timer>
                    <e2servicereference>1:256:19:88:E:85:C00000:0:0:0:rtsp://XXXXX%3aXXXXX@XXXXX%3a554/stream?ref=1%3a0%3a19%3a88%3aE%3a85%3aC00000%3a0%3a0%3a0%3a</e2servicereference>
                    <e2servicename>//XXXXX:XXXXX@XXXXX:554/stream?ref=1:0:19:88:E:85:C00000:0:0:0:</e2servicename>
                    <e2eit>3380</e2eit>
                    <e2name>Two and a Half Men</e2name>
                    <e2description>Feuchtfr..hliche Weihnacht</e2description>
  • Dann muss ich nochmal schauen. Deine links sind halt schon ganz anders.


    Solange das ohne side effects eingebaut werden kann ok. Aber sonst musst du dir selbst das plugin patchen.

    Gruss
    Dre


    Boxen (im Einsatz): DM920, DM900, DMOne
    Developer Project Merlin - we are OpenSource

  • Hmm. Meine Links sind aber doch bis auf die folgenen zwei Unterschiede gleich:
    1) rtsp:// statt http://
    2) :554/stream?ref= statt :8001/


    Eigentlich ist es aber doch total egal wie die Links aussehen. Der Aufbau der ServiceRef ist soweit ich weiss immer gleich. Sie ist in 10 bis 12 Teile unterteilt, die durch : getrennt sind. Die ersten 10 Teile geben die "ID" des Kanals an. Der 11. Teil die URL (optional) und der 12. Teil den Namen (optional).


    Daher hat mein Code einfach die gesamte sref bis zum 10. : gesplittet. Mein Array hat also höchtens 11 Felder gehabt. Wenn das 11. Feld vorhanden war, hat es entweder "[url]:[name]" enthalten oder nur "[url]" bzw nur "[name]". Das wird dann auf "" gesetzt. Hätte man auch mit del löschen können, dann hätte aber nach dem join der Doppelpunkt am Ende gefehlt, der ansonsten auch bei normalen Sendern bei mir immer vorhanden war.


    Was mein split-Code einfach nur macht, ist alles nach dem 10. ":" abschneiden. Egal wie die Url aufgebau ist, egal ob da noch ein Name hinterherkommt und egal ob DMM irgendwann noch ein zusätzliches Feld einbaut und unterstützt. Ist das nicht genau das Verhalten, das eigentlich richtig ist?

  • Ich möchte mich hier mal gerne einklinken :kissing_face:


    Ich habe die Ausgangssituation nicht ganz verstanden... :confused_face:


    Also, ich gebe mal wieder, was ich verstanden habe... :grinning_squinting_face:


    Du hast Dir auf Deinem Client die Bouquets der Serverbox geholt, und dann händisch die http's als rtsp abgeändert? Ist das richtig?


    Was Du dann versuchst zu machen verstehe ich nicht ganz. Du willst einen Remote(?)-Timer setzen, von der Client Box auf die Serverbox? Mit dem rtsp Service? Sprich die Serverbox soll den Kanal aufnehmen, natürlich aber mit derer lokalen Servicereference? Sehe ich das richtig? Und das geht nicht (was logisch ist, weil wie Du ja schon bemerkt hast, wird in der Funktion getServiceRef auf http untersucht und nicht auf rtsp) ?


    Also wenn ich das so richtig verstanden habe, ist das ein Weg, den ich so gar nicht implementiert habe. Von der Client-Box einen Timer des Partnerbox-Services auf die Serverbox "zurückzulegen". Da müsste ich nämlich auch das live-Flag in der Servicereference wieder zurücksetzen...also das geht zwar, aber 100% richtig ist das nicht, weil die Servicereference des Timereintrags ein live-flag besitzt. Somit wirst Du das Timersymbol nämlich nicht in der EPGSelection der Serverbox sehen.


    Sag mir mal bitte, ob ich das alles bisher richtig verstanden habe :smiling_face:

  • Genau, ich habe mir die Bouquets der Serverbox mit Hilfe des Partnerbox-Plugins auf der Client-Box eingerichtet und dann manuell die http-Url gegen die rtsp-Url ausgetauscht.


    Mehr habe ich nicht gemacht und möchte auch keine exotischen Funktionen nutzen oder irgendetwas zurücklegen, sondern lediglich die ganz normalen Remote-Timer nutzen. D.h. einfach vor der Client-Box sitzen und einen neuen Timer, der bisher nirgends hinterlegt war, erstellen. Aufnehmen soll diesen dann die Server-Box.


    Dabei entsteht dann das Problem, dass getServiceRef die sref nicht korrekt abschneidet, weil nur nach "http", aber nicht nach "rtsp" gesucht wird.


    Was das mit dem Live-Flag zu tun hat, verstehe ich ehrlich gesagt nicht. Ich möchte einfach nur, dass ein Timer für meine rtsp-Kanäle auf die gleiche Weise angelegt werden kann wie man das für normale Partnerbox-Kanäle machen könnte. Da werden ja auch nur die ersten 10 "Felder" der sref übertragen.


    Für die Verwirrung dadurch, dass ich von fehlerhaftem Encoding gesprochen habe, entschuldige ich mich :smiling_face: - Ich hatte schlicht den Fehler falsch interpretiert und nicht auf dem Schirm, dass die sref normalerweise abgeschnitten wird.


    Falls weitere Verwirrung entstand, weil ich die Rückgabe von timerlist hier gepostet habe: Nochmals sorry :smiling_face: - Die werte ich nicht aus, sondern habe sie nur mit tcpdump mitgeschnitten. Ich wollte damit einfach nur zeigen, was für ein Fehler entsteht, wenn die sref nicht nach dem 10. Feld, sondern erst nach dem 11. Feld (was dre's Code anscheinend so gemacht hat) abgeschnitten wird. Anscheinend wird nämlich dann das Feld, das bei 12stelliger sref die Url enthält, als Sendername interpretiert. Meine Schlussfolgerung ist: Einfach die sref immer und überall nach dem 10. Feld abschneiden. Genau das macht der Patch, den ich heute gepostet hatte. Und Partnerbox-Kanäle mit http-Url werden mit dem Code weiterhin an genau der gleichen Stelle abgeschnitten wie vorher. Es ändert si h somit nichts an der Funktionalität, außer dass damit dann auch andere Url-Typen untersützt werden.

  • Ok, dann hatte ich es ja doch richtig verstanden.
    Vergiss mal das live-flag, ist egal, und hat auch nix mit Deiner Sache zu tun.


    Ändere die getServiceRef-Funktion in PartnerboxFunctions.py wie folgt:


    Python
    def getServiceRef(sreference):
    	serviceref = sreference
    	hindex = sreference.find("http")
    	if hindex > 0: # partnerbox service ?
    		serviceref =  serviceref[:hindex]
    	else:
    		hindex = sreference.find("rtsp")
    		if hindex > 0: # rtsp partnerbox service ?
    			serviceref =  serviceref[:hindex]
    	return serviceref


    Das geht bei mir so, wie Du es haben willst, nachdem ich mir einen rtsp Eintrag angelegt hatte, bei dem ich die http-url durch die entsprechende rtsp-url ersetzt habe.



    Code
    #SERVICE 1:256:19:283D:3FB:1:C00000:0:0:0:rtsp%3a//blablubla%3a554/stream?ref=1%3a256%3a19%3a283D%3a3FB%3a1%3aC00000%3a0%3a0%3a0%3a:Das Erste HD (dreambox)
    #DESCRIPTION Das Erste HD (dreambox)


    Gib Bescheid, ob das nun bei Dir auch so geht :winking_face:

  • Das kann ich leider grad schlecht testen, sieht aber vom Code her so aus, als wenn es funktioniert :smiling_face:


    Und da Du das bei Dir getestet hast, wird es bei mir auch sicher funktionieren. Wenn das bei Gelegenheit so ins git und somit auf den feeds übernommen wird, bin ich glücklich. Dann muss ich das nicht nach jedem Update selbst patchen. :grinning_squinting_face:


    Danke!