HacMat Posted November 9, 2016 Share Posted November 9, 2016 Hallo,Die erst kürzlich dokumentierten Parameter 'pre=' und 'post=' des API Requests '/api/timeradd.html' sind bei Timern bei der PDC genutzt wird ohne Wirkung.Bei gewöhnlichen Timern, d.h. ohne die Überwachung des EPGs zur Festlegung der Start- und Stoppzeiten, funktionieren die Parameter dagegen erwartungsgemäß.Beispiel:Timer mit PDC.../api/timeradd.html?ch=2359890548428909414&title=Wetter&dor=42693&pre=3&start=1160&stop=1165&post=1&allowdup=1&folder=Auto&action=0&ttx=0&subs=0&audio=0&eit=0&monitorpdc=1&monforrec=2&pdc=646356&encoding=255&enable=1Erzeugt wurde der folgende Eintrag in dem mit '/api/timerlist.html?utf8=' abrufbaren XML Dokument: <Timer Type="1" ID="{220560C3-F844-43DE-921B-E1DD56A02E9F}" Enabled="-1" Priority="50" Charset="255" Date="19.11.2016" Start="19:20:00" Dur="5" End="19:25:00" Action="0" EPGEventID="17887" PDC="646356"> <Descr>Wetter</Descr> <Options AdjustPAT="-1" MonitorPDC="2" RunningStatusSplit="-1"/> <Format>2</Format> <Folder>Auto</Folder> <NameScheme>%year-%date_%time_%station_%name</NameScheme> <Source>API</Source> <Channel ID="2359890548428909414|ZDF HD (deu)"/> <Executeable>-1</Executeable> <Recording>0</Recording> <ID>18</ID> <GUID>{220560C3-F844-43DE-921B-E1DD56A02E9F}</GUID> </Timer>Timers ohne PDC.../api/timeradd.html?ch=2359890883043667700&title=RTL+II+Wetter&dor=42695&pre=3&start=1214&stop=1215&post=10&allowdup=1&folder=Auto&action=0&ttx=0&subs=0&audio=0&eit=0&monitorpdc=0&monforrec=0&encoding=255&enable=1Erzeugt wurde dieser Eintrag: <Timer Type="1" ID="{9A6B1D97-AB74-4E98-8EE4-C9C856B42E39}" Enabled="-1" Priority="50" Charset="255" Date="21.11.2016" Start="20:14:00" Dur="1" End="20:15:00" PreEPG="3" PostEPG="10" Action="0"> <Descr>RTL II Wetter</Descr> <Options AdjustPAT="-1"/> <Format>2</Format> <Folder>Auto</Folder> <NameScheme>%year-%date_%time_%station_%name</NameScheme> <Source>API</Source> <Channel ID="2359890883043667700|RTL2"/> <Executeable>-1</Executeable> <Recording>0</Recording> <ID>19</ID> <GUID>{9A6B1D97-AB74-4E98-8EE4-C9C856B42E39}</GUID> </Timer> Ich verwende die Version 1.33.1.0. VG,HacMat Quote Link to comment
Griga Posted November 10, 2016 Share Posted November 10, 2016 Bestätigt. Der RS versucht, eine Unzulänglichkeit des DVBViewer auszubügeln, der das API ebenfalls benutzt. Bei der Erzeugung eines Timers rechnet der DVBViewer die Vor- und Nachlaufzeit sofort der Start- und Endzeit hinzu, so dass sie danach nicht mehr als separater Wert zur Verfügung steht. Wenn PDC verfügbar ist und sich ein EPG Eintrag mit ausreichender Sicherheit zuordnen lässt, versucht der RS, damit die Vor- und Nachlaufzeit zu rekonstruieren, d.h. er rechnet Vorlauf = tatsächliche Startzeit minus angegebene Startzeit und Nachlauf = angegebene Endzeit minus tatsächliche Endzeit. Falls das Ergebnis negativ ist, setzt er es auf 0. Das ist für andere API-Benutzer unschön. Insbesondere, da man nicht fest mit diesem Mechanismus rechnen kann. Wenn der EPG-Eintrag aus welchem Grund auch immer nicht zur Verfügung steht, funktioniert es natürlich nicht. Schade, dass es dir erst kurz nach dem 1.33.2 Release aufgefallen ist. Sonst hätte man vielleicht noch was daran machen können. Im Grunde erscheint es unsinnig, dass der RS versucht, Vor- und Nachlauf selbst zu ermitteln, wenn sie angegeben werden. Allerdings müssten die Konsequenzen einer entsprechende Änderung erst genauer untersucht werden. Das ganze Timer-Handling des DVBViewers mit seinen Abweichungen gegenüber dem RS bräuchte eine Überarbeitung. Irgendwann werde ich hoffentlich Zeit dafür finden. Quote Link to comment
HacMat Posted November 10, 2016 Author Share Posted November 10, 2016 Vielen Dank für die ausführliche Erklärung, Griga. So gesehen ist es ja kein Bug, sondern beabsichtigt.Ich habe festgestellt, dass es zwingend erforderlich ist, bei 'start=' und 'stop=' den Vorlauf bzw. Nachlauf mit einzurechnen. Und zwar unabhängig davon, ob PDC und ein EPG-Eintrag verfügbar, oder nicht verfügbar ist. Das ist nur umständlich, aber sonst eigentlich nicht weiter problematisch. Rechnet man den Vorlauf und den Nachlauf immer mit ein, funktioniert alles perfekt.Solltest Du es aber doch mal ändern wollen:Ändere besser nicht das Verhalten von 'pre=' und 'post='. Die Kompatibilität zu älteren DVBViewer-Versionen würde nur unnötigerweise beeinträchtigt. Ich würde einfach 2 neue Parameter (z.B. 'prestart' und 'poststop') einführen, bei denen das verwirrende und umständliche Einrechnen des Vorlaufs und des Nachlaufs entfällt.'pre und 'post' könnte man dann in der Doku als obsolet kennzeichnen und auf die neuen Parameter verweisen. Quote Link to comment
Griga Posted November 11, 2016 Share Posted November 11, 2016 Danke für das Feedback. Ich werde es mir bei nächster Gelegenheit noch mal genauer anschauen. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.