Jump to content
HacMat

API-Bug? Request '/api/timeradd.html': 'pre=' und &#39

Recommended Posts

HacMat

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=1

Erzeugt 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=1

Erzeugt 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

Share this post


Link to post
Griga

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.

Share this post


Link to post
HacMat

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.

Share this post


Link to post
Griga

Danke für das Feedback. Ich werde es mir bei nächster Gelegenheit noch mal genauer anschauen.

Share this post


Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...