Recording Service API

[Lars_MQ]

The response of the get request is:

"Template not prepared!"

http://192.168.178.10:8089/timeradd.html use the URL as described there.

[Goersch]

Hello Lars, that link doesn't work ...

 

If this was you link http://www.DVBViewer.info/forum/index.php?showtopic=37211&pid=271395&mode=threaded&start=#entry271395 ://http://www.DVBViewer.info/forum/ind...t=#entry271395

that's where i started.

 

I guess I have a problem with dor, start or stop. Here again my questions from a previous post

- integer, calculated by round(onlythetime * minsperday) - which information includes "onlythetime" ?

- the integer part of the floatdatetime value - which integer part ?

Edited May 26, 2010 by Goersch

[dgdg]

Hallo,

 

ich versuche das EPG über die Web-API des Recording Service auszulesen. Das klappt auch einwandfrei bei fast allen Sendern, die ich benötige. Nur bei EinsPlus bekomme ich nichts zurück.

 

Hier die errechnete URL:

url=http://username:passwort@127.0.0.1/api/epg.html?lvl=2&channel=562954317295667&start=40324.7611&end=40331.7611

 

und hier die dafür verwendeten Parameter:

tuner=1, nid=1, tid=1051, sid=28723

 

Sieht da jemand einen Fehler?

 

 

Und könnte man die Web-API nicht dahin gehend erweitern, dass man den gewünschten Sender auch einfach als Name übergeben kann? Ich finde es ziemlich umständlich, dass ich in meinem Programm händisch eine Liste der Senderparameter anlegen (und pflegen) muss, die ich dann an die API übergebe. Oder wie kommt man sonst an die Daten ran um die EPGChannelID zu berechnen?

 

Und habe ich das richtig verstanden, dass die EPGChannelID wiederum ganz anders berechnet wird als die ChannelID (=FavoritenID?), die man bei timeradd benötigt?

 

Und dieses Float-Datum-Format hat mich auch mindestens eine Stunde gekostet (und funktioniert immer noch nicht richtig). Dabei könntest man das doch im Recording Service, der ja vermutlich in Delphi geschrieben ist, sicher viel leichter umrechnen, also diejenigen, die mit irgendeiner Programmiersprache auf die API zugreifen.

Edited May 26, 2010 by dgdg

[Goersch]

Und könnte man die Web-API nicht dahin gehend erweitern, dass man den gewünschten Sender auch einfach als Name übergeben kann? Ich finde es ziemlich umständlich, dass ich in meinem Programm händisch eine Liste der Senderparameter anlegen (und pflegen) muss, die ich dann an die API übergebe. Oder wie kommt man sonst an die Daten ran um die EPGChannelID zu berechnen?

 

Und habe ich das richtig verstanden, dass die EPGChannelID wiederum ganz anders berechnet wird als die ChannelID (=FavoritenID?), die man bei timeradd benötigt?

 

Und dieses Float-Datum-Format hat mich auch mindestens eine Stunde gekostet (und funktioniert immer noch nicht richtig). Dabei könntest man das doch im Recording Service, der ja vermutlich in Delphi geschrieben ist, sicher viel leichter umrechnen, also diejenigen, die mit irgendeiner Programmiersprache auf die API zugreifen.

 

Unterschreib ich auch alles - oder mindestens eine ID für einen Sender (z.B. verwendet ForTheRecord Guids) wäre hilfreich.

 

Und danke für deine url - wie ich sehe, muss man gar nicht einen Integer übergeben, sondern die komplette Zeit als float. Hoffentlich ist das Ergebnis der ToOADate() Methode von DateTime ...

 

 

Klappt leider auch nicht:

url = "http://192.168.178.10:8089/timeradd.html?ch=1080454602&dor=40326.8299&start=40326.8299&stop=40326.8507&title=Tagesschau&encoding=255&enable=1&action=0&endaction=0"

 

Frage: Muss die ChannelID so: "1080454602" oder so "1080454602|Das Erste (deu)" übergeben werden ?

Edited May 26, 2010 by Goersch

[dgdg]

Vorsicht. So wie ich die Zeit übergebe, funktioniert es nicht richtig. Könnte also auch sein, dass ich da noch was nicht richtig verstanden habe.

Oder ich habe noch einen Rechnerfehler drin.

 

Also meine Timer-Umrechnung scheint nun doch ok zu sein. Jedenfalls bekomme ich das EPG im richtigen Zeitraum.

 

Mangels ToOADate() muss ich mir das aber mühsam über Unix-Time und Differenz zwischen dem 1.1.1970 und dem 30.12.1899 ausrechnen. Aber wenn man's einmal ausgetüftelt hat, ist es ja ok.

Edited May 26, 2010 by dgdg

[Goersch]

Ich kann ja verstehen, dass diese API für interne Zwecke entstanden ist und deshalb die IDs und Datentypen übergeben werden, mit denen sowieso schon intern gearbeitet wird. Trotzdem könnte man das mit wenig Aufwand deutlich konfortabler machen.

da bin ich auch bei Dir.

 

Bzgl. der ChannelID solltest Du auch aufpassen. Wie schon geschrieben, mir ist nicht klar, ob der Name mit einem | davor auch zur ChannelID gehört. Bei dem COM Interface funktioniert es so

 

Hab nun noch mindestens 10-20 unterschiedliche URLs ausprobiert, aber keine einzige klappt. Ich hoffe, dass Lars weiterhelfen kann...

[nuts]

Hm die Zeitangabe sollte zwischen 0000 und 1000 liegen, soweit ich das noch richtig in Erinnerung habe.

Das war damals aber auch nur mit meinem Halbwissen hergeleitet.

edit\ Und bezog sichs aufs EPG, bei den Timern ists ja wieder ganz anders.

Edited May 26, 2010 by nuts

[Lars_MQ]

Hello Lars, that link doesn't work ...

Sorry copy and paste problem

This one: http://www.DVBViewer.info/forum/index.php?...st&p=268968 there is URL defined.

 

http://192.168.178.10:8089/api/timeradd.html?....

[Lars_MQ]

Float-Datum-Format

So wie es standard mäßig auch in COM verwendet wird.

 

dass man den gewünschten Sender auch einfach als Name übergeben kann?

Ich habe diverse Sender die mehrfach vorhanden sind aus unterschiedlichn empfangsquellen. Wir haben uns schon was dabei gedacht, das genau so zu machen.

[Goersch]

So wie es standard mäßig auch in COM verwendet wird.

 

bei der COM Schnittstelle übergeb ich meine DateTime Objekt -den Rest macht COM

[nuts]

Siehste da hast du es doch schon ganz schön gut: http://www.DVBViewer.info/forum/index.php?showtopic=38502

Klappt das nu? Sonst versuche ich mal ein Beispiel für den Timer zu machen.

[dgdg]

So wie es standard mäßig auch in COM verwendet wird.

Ja, habe inzwischen auch gefunden, das sich wohl Microsoft diesen Mist ausgedacht hat. ;-)

 

Ich habe diverse Sender die mehrfach vorhanden sind aus unterschiedlichn empfangsquellen. Wir haben uns schon was dabei gedacht, das genau so zu machen.

Das habe ich mir gedacht, dass ihr euch was dabei gedacht habt. ;-)

 

Trotzdem ist ein Int64 mehr als unhandlich, wenn man keine Int64-Datentypen zur Verfügung hat.

Warum dann nicht wenistens als Hex-Wert. Dann könnte man sich das wenigstens noch String-technisch sehr einfach aus 2 x Int32 oder 4 x Iin16 zusammenbauen.

[Goersch]

Sorry copy and paste problem

This one: http://www.DVBViewer.info/forum/index.php?...st&p=268968 there is URL defined.

 

doesn't really help - that's where I started. It would be great, if you could have a view at one of my urls and let me know what is wrong or send a working url

 

The target is to record 28.05.2010 20:00 - 20:15 ARD Tagesschau

 

Some of my variables show following values

startTime = 40326.829861111109 (Would that be the correct value for your system as well ?)

endTime = 40326.850694444445 (Would that be the correct value for your system as well ?)

 

Now I have several questions/options:

a) The ChannelID I get from the COM Interface is "1080454602|Das Erste (deu)". To use addtimer.html, do I have to use

ch=1080454602

ch=1080454602|Das Erste (deu)

ch=1080454602|Das+Erste+(deu)

 

What do I have to pass to dor ?

dor=40326

dor=40326.829861111109

dor=?

 

c) How (the description is not very clear) do I have to pass to start/stop parameters

&start=xxxxx/stop=xxxxxx&....

&start=xxxxx&stop=xxxxxxx&.....

 

d) How do I have to calculate the values for start/stop

start=0.829861111109*24h*60min

start=40326.829861111109

start=ROUND(40326.829861111109*24h*60min)

start=?

 

I have tried nearly all of these possibilities - but without beeing successfully.

 

It would be great if you could give me a working example from your system - I know, I have to change the ChannelId then, but I get to know about my problem.

[Goersch]

Siehste da hast du es doch schon ganz schön gut: http://www.DVBViewer.info/forum/index.php?showtopic=38502

Klappt das nu? Sonst versuche ich mal ein Beispiel für den Timer zu machen.

 

also ich bin bei dem Timer noch nicht weiter

[Lars_MQ]

http://admin:admin@mypc/api/timeradd.html?enable=1&ch=1080454602%7CDas%20Erste%20%28deu%29&dor=40326&start=1197&stop=1218&days=-------&action=0&endact=0&title=Tagesschau

So sieht das aus, wenn der Viewer nen Timer an den Recservice sendet. Merke: Strings müssen URL encoded sein, siehe den ch parameter.

 

Beachte: ich nutze den Servernamen (mypc) auf Port 80. Das musst Du bei Dir natürlich ersetzen.

 

WICHTIG

Nachtrag: der timer geht von 20:10 - 20:25, Sorry ich hatte meine vor/nachlaufzeiten nicht beachtet.

[Lars_MQ]

start=0.829861111109*24h*60min

start=round(0.829861111109*24h*60min)

Ich dachte das ist eigentlich sehr klar: (integer, calculated by round(onlythetime * minsperday))

[Lars_MQ]

Hm die Zeitangabe sollte zwischen 0000 und 1000 liegen, soweit ich das noch richtig in Erinnerung habe.

Genauer 0 >= zeitangabe <= (24*60) -1

[nuts]

Hö?

 

Zeit (int) / 2400 (int) * 24*60 oder?

z.B. 23.00 Uhr = 2300/2400 * 60 * 24 = 1368

Bereich: 0-1440?

 

edit\ also für den Timer jetzt.

Edited May 26, 2010 by nuts

[Lars_MQ]

Nein

Bereich: 0-1439 (00:00 - 23:59) Wohlgemerkt ausgehend von der Floattime.

 

Zeit und Datum werden zerlegt. Datum = Zahl vor dem komma, Zeit = Round(Nachkommaanteil * 24 * 60).

 

Die Stoppzeit definiert sich alleine durch die Zeit, da timer a. variables Datum haben können und b. 24 h länge nicht überschreiten können...

[dgdg]

Also ich habe jetzt mal folgende URL "ausgerechnet", um einen Timer für heute (26.5.) von 23 Uhr bis 1 Uhr auf DasErste einzufügen:

 

http://username:passwort@127.0.0.1/api/timeradd.html?ch=1080454602&dor=40356&start=1380&stop=60&enable=1&action=0&title=Dies%20ist%20ein%20Test

 

Klappt leider nicht. Wo ist der Fehler?

Edited May 26, 2010 by dgdg

[Lars_MQ]

Oh er wird angelegt.

 

ABER

40326 ist der 28.5.

40356 ist der 27.06.

 

Das Erste (deu) So 27.06 23:00 - 01:00 Dies ist ein Test

[dgdg]

Oh er wird angelegt.

 

ABER

40326 ist der 28.5.

40356 ist der 27.06.

 

Ok, stimmt. Für den 27.6. habe ich inzwischen einige Einträge (soweit hatte ich nicht nach unten gescrollt). Jetzt weiss ich, wo ich suchen muss. ;-)

 

Kannst Du mir vielleicht auch noch sagen, warum ich das EPG von http://www.DVBViewer.info/forum/index.php?...st&p=299376 nicht bekomme?

[Lars_MQ]

Kein EPG da? ich habs grade bei mir im browser eingegeben und die xml erscheint wie erwartet...

[dgdg]

Kein EPG da? ich habs grade bei mir im browser eingegeben und die xml erscheint wie erwartet...

 

Jetzt geht es hier auch. Und ich habe keine Idee, was sich geändert hat. Das EPG war jedenfalls auch vorher schon im Web Interface vorhanden und die gepostete URL, hatte definitiv nicht funktioniert. Egal, jetzt geht's.

 

Der Fehler bei timeradd war auch schnell gefunden. In ActionScript beginnt der Monat mit 0 und nicht mit 1. Das wusste ich zwar, aber bei der Testroutine habe ich nicht daran gedacht.

 

Damit sind meine Probleme gelöst: EinsPlus liefert ein EPG und Timer lassen sich anlegen.

 

Danke an Lars für die schnelle Unterstützung!

Edited May 26, 2010 by dgdg

[dgdg]

Jetzt geht es hier auch. Und ich habe keine Idee, was sich geändert hat. Das EPG war jedenfalls auch vorher schon im Web Interface vorhanden und die gepostete URL, hatte definitiv nicht funktioniert. Egal, jetzt geht's.

 

Jetzt geht es plötzlich wieder nicht mehr (das EPG von EinsPlus).

 

Wenn ich die vom Programm erzeugte URL in Firefox oder IE eingeben, dann funktioniert es. Schicke ich die URL vom Programm aus, dann geht es nur bei EinsPlus nicht. Die anderen Sender funktionieren.

 

Sehr seltsam.

[Goersch]

http://admin:admin@mypc/api/timeradd.html?enable=1&ch=1080454602%7CDas%20Erste%20%28deu%29&dor=40326&start=1197&stop=1218&days=-------&action=0&endact=0&title=Tagesschau

So sieht das aus, wenn der Viewer nen Timer an den Recservice sendet. Merke: Strings müssen URL encoded sein, siehe den ch parameter.

 

Beachte: ich nutze den Servernamen (mypc) auf Port 80. Das musst Du bei Dir natürlich ersetzen.

 

WICHTIG

Nachtrag: der timer geht von 20:10 - 20:25, Sorry ich hatte meine vor/nachlaufzeiten nicht beachtet.

 

Ich glaub, ich muss "notgeschlachtet" werden - wenn ich den Text oben übernehme (nach Änderung des IP Adresse etc.) , kommt immer noch "Template not prepared". Ich werd jetzt das mal aus dem Code heraus versuchen. Ich weiß ja jetzt, wie die Zeiten berechnet werden

 

Danke !

Georg

[dgdg]

Ich glaub, ich muss "notgeschlachtet" werden - wenn ich den Text oben übernehme (nach Änderung des IP Adresse etc.) , kommt immer noch "Template not prepared". Ich werd jetzt das mal aus dem Code heraus versuchen. Ich weiß ja jetzt, wie die Zeiten berechnet werden

 

Funktioniert bei dir der Abruf des EPG? Welche Programmierumgebung verwendest Du? Die Meldung mit dem Template lässt mich vermuten, dass dein Programm ein Problem mit der zurückgelieferten XML-Datei hat.

 

Wobei, timeradd liefert ja gar keine XML-Datei! zurück.

Edited May 27, 2010 by dgdg

[Goersch]

Funktioniert bei dir der Abruf des EPG? Welche Programmierumgebung verwendest Du? Die Meldung mit dem Template lässt mich vermuten, dass dein Programm ein Problem mit der zurückgelieferten XML-Datei hat.

 

Wobei, timeradd liefert ja gar keine XML-Datei! zurück.

 

Visual Studio Standard C# - aber das ist nicht das Problem; es funzt jetzt Ich hab die ganze Zeit das "/api/" nicht in der url gehabt

 

Mit dem EPG mach ich nix. Mein Programm liest aus Klack.de oder TVInfo den Merkzettel und trägt diesen dann bei einem Aufnahmeprogramm ein

(im Moment werden DVBViewer und MediaPortal) unterstützt. Hier ein Link :GMPS

Ab heute wird dann auch der DVBViewer Recording Service unterstützt Zwar noch nicht 100%, aber der Anfang ist gemacht

 

Ich haben die OT Beiträge mal abgetrennt:

http://www.DVBViewer.info/forum/index.php?showtopic=40830

Edited May 28, 2010 by Tjod

[Prinz]

Hallo,

 

http://admin:admin@mypc/api/timeradd.html?enable=1&ch=1080454602%7CDas%20Erste%20%28deu%29&dor=40326&start=1197&stop=1218&days=-------&action=0&endact=0&title=Tagesschau

 

Bei der Programmierung des DVBViewerTimerImport-Tools habe ich festgestellt, dass diese Art der Programmierung des Timers nicht so ganz optimal ist.

 

Mit einem solchen Format gibt es immer Mehrdeutigkeiten bei der Sommer/Winterzeit-Umschaltung.

 

Wäre es nicht günstiger hier einfach als Zeit die GMT einzuführen. Die ist eindeutig und jedes vernünftige Betriebssysteme arbeitet intern auch mit dieser Zeit und gaukeln dem User nach außen hin nur die Ortszeit vor.

 

Der User wäre natürlich mit dieser Zeit überfordert, daher sollte man die GUIs natürlich so belassen, aber wenn eine Applikation den Timer setzt, wäre das IMO einfach sauberer. Jede Programmiersprache kennt heutzutage Funktionen/Methoden eine Ortszeit in die GMT-Zeit umzurechnen.

 

Wäre da etwas möglich?

 

Gruß

Prinz

[Goersch]

Hallo Lars,

 

hab noch ein Problem mit den Umlauten - trotz url encode.

 

Aufgenommen werden soll: Hör mal wer da hämmert. Übergebene Url (Kanal und Uhrzeit falsch - es geht nur um den Titel)

 

url = "http://192.168.178.10:8089/api/timeradd.html?ch=1080454602%7cDas+Erste+(deu)&dor=40330&start=1194&stop=1225&title=H%u00f6r+mal+wer+da+h%u00e4mmert&enable=1&action=0&endaction=0"

 

Der Titel steht so im Timer : H%u00f6r mal wer da h%u00e4mmert

 

Mach ich da noch was falsch ?

[Lars_MQ]

welche encodierung nutzt du? Sieht aus wie unicode...

[Goersch]

welche encodierung nutzt du? Sieht aus wie unicode...

 

ja, stimmt. Ich denke, ich muss den Encoding Parameter noch setzen. Aber auf was ? Oder soll ich UTF 8 verwendet und Encoding=255 übergeben ?

[Lars_MQ]

Ja, sorry, da musste ich jetzt auch erstmal nachschauen.

 

Also encoding parameter nicht vorhanden = das lokale encoding wird genommen (bei uns wäre das ANSI).

Encoding parameter = 255 => UTF8 wird genutzt.

 

Ich weiss, ist nicht grade eine super konstruktion, aber nur so laufen ANSI und Unicode DVBViewer Versionen, ohne dass es zu problemen kommen. Gelobt sei die Rückwärts kompatibilität...

[Goersch]

Ja, sorry, da musste ich jetzt auch erstmal nachschauen.

 

Also encoding parameter nicht vorhanden = das lokale encoding wird genommen (bei uns wäre das ANSI).

Encoding parameter = 255 => UTF8 wird genutzt.

 

Ich weiss ist nicht grade eine super konstruktion, aber nur so laufen ANSI und Unicode DVBViewer Versionen, ohne dass es zu problemen kommen. Gelobt sei die Rückwärts kompatibilität...

 

Ok, mit UTF8 sieht es gut aus

[majstang]

Most api calls are simple http-get calls.

 

the basic url is:

http://[user:password@]IP[:port]/api

I assume if you going to mess with a web api you know what this means and which parameters are needed or not.

if I refer to URL in the examples I mean the above construct.

 

All answers are xml "files"

 

The Status of the service:

url/status.html

Is this the only way to query the status of the service (if recordings are active or not)? Is there some other way or maybe some windows process that changes whenever a recording is active. The only trace in windows (if not using the webinterface) when a recording starts seem to be the RS tray icon goes red.

Edited June 1, 2010 by majstang

[Prinz]

Hi,

Is this the only way to query the status of the service (if recordings are active or not)?

 

This is the only way I know.

 

Regards

Prinz

[majstang]

Hi,

 

 

This is the only way I know.

 

Regards

Prinz

Thanks Prinz!

So, no change in registrykeys either then when a recording starts? Uhh, this is akward to say at least. Im making a script that is supposed to behave in different ways depending on recording service status. It is not so easy to make the script first query the webinteface for RS status and then create a XML file with the answer and then read that file to extract the answer into a variable my script understands. Unless somebody has some other ideas on how to accomplish this in an easy way?

This had been so easy if lets say a new process (recordingprocess) was created in devicemanager whenever a recording starts and then query if this process exist or not.

 

Regards

Majstang

Edited June 2, 2010 by majstang

[Goersch]

Ok, mit UTF8 sieht es gut aus

 

Ich hab da eine kleine Bitte Könntest Du in einer zukünftigen Version des RecordingService als Antwort auf ein erfolgreiches timeradd die timer id zurückgeben ? (also nicht nur die Fehlermeldungen)

Ist nicht wahnsinnig wichtig - würde aber sehr helfen, da ich nach jedem timeradd die vorhandenen Timer auslesen muss, um dann die TimerId rauszufischen. hin und wieder scheint es so, als ob beim Auslesen der Timer der neue Timer noch nicht in der Liste vorhanden ist und damit hat mein GMPS ein Problem

[Prinz]

Hallo,

 

Ich hab da eine kleine Bitte Könntest Du in einer zukünftigen Version des RecordingService als Antwort auf ein erfolgreiches timeradd die timer id zurückgeben ? (also nicht nur die Fehlermeldungen)

 

Bitte eine solchen Änderung aber rechtzeitig mitteilen, was im Falle einer Fehlermeldung zu erwarten ist und was, wenn der Eintrag geklappt hat.

 

Aktuell erwartet das DVBViewerImport-Tool, dass bei einer fehlerfreien Programmierung nichts zurückkommt.

 

Sauberer wäre natürlich immer eine Quittierung, die auch in Form einer ID erfolgen kann.

 

@Goersch:

Bzgl. dieser ID ist zu beachten, dass diese ID bei einem Neustart des Services für die gleiche Aufnahme einen anderen Wert haben kann! Ich lese daher grundsätzlich immer die Aufnahmeliste neu ein, wenn ich eine vorhandene Aufnahme verändern oder löschen will, da man nie wissen kann, ob jemand zwischendurch beispielsweise durch Änderung der Service-Konfiguration den Service neu gestartet hat.

 

Diese Einschränkung gilt nicht nur für den Service sondern auch für den DVBViewer, da in den entsprechenden XML-Dateien die IDs leider nicht eingetragen werden.

 

Aktuell versucht daher das DVBViewerImportTool die richtige Zuordnung aus den Anfangs- und Endzeiten zu gewinnen und wenn die nicht eindeutig ist , weil beispielsweise der User die Anfangs/Endzeit verändert hat, noch zusätzlich aus dem Titel. Beim Titel habe ich quasi eine Fuzzy-Logik eingebaut, da der User den Titel auch etwas verändert haben könnte.

 

Diese Zuornung der Aufnahme ist eigentlich sehr unschön, so dass es besser wäre, wenn die IDs fest wären (auch nach Neustart), dann könnte man sich diesen Zuordnungsaufwand sparen.

 

Gruß

Prinz

Edited June 2, 2010 by Prinz

[Goersch]

Bzgl. dieser ID ist zu beachten, dass diese ID bei einem Neustart des Services für die gleiche Aufnahme einen anderen Wert haben kann! Ich lese daher grundsätzlich immer die Aufnahmeliste neu ein, wenn ich eine vorhandene Aufnahme verändern oder löschen will, da man nie wissen kann, ob jemand zwischendurch beispielsweise durch Änderung der Service-Konfiguration den Service neu gestartet hat.

 

Diese Einschränkung gilt nicht nur für den Service sondern auch für den DVBViewer, da in den entsprechenden XML-Dateien die IDs leider nicht eingetragen werden.

 

Aktuell versucht daher das DVBViewerImportTool die richtige Zuordnung aus den Anfangs- und Endzeiten zu gewinnen und wenn die nicht eindeutig ist , weil beispielsweise der User die Anfangs/Endzeit verändert hat, noch zusätzlich aus dem Titel. Beim Titel habe ich quasi eine Fuzzy-Logik eingebaut, da der User den Titel auch etwas verändert haben könnte.

 

Diese Zuornung der Aufnahme ist eigentlich sehr unschön, so dass es besser wäre, wenn die IDs fest wären (auch nach Neustart), dann könnte man sich diesen Zuordnungsaufwand sparen.

 

Danke für den Hinweis bzgl. der Änderungen - das war mir schon bei dem DVBViewer aufgefallen und ist nicht wirklich schön.

 

Ja, mir würde es auch helfen, wenn die IDs fest und eindeutig sind (z.B. GUIDs).

 

Mh, warum vergleichst Du die Endzeit ? eine Aufnahme ist für mich durch KanalNamen und StartZeit eindeutig definiert.

 

Was hier noch "unschön" ist (im Vergleich zu MediaPortal), ist, dass die Vor- und Nachlaufzeit nicht einzeln pro Aufnahme abgefragt werden kann, sondern bereits in Start- und Endzeit verrechnet ist - somit entstehen halt neue Start- und Endzeiten wenn diese Zeiten verändert werden, ohne dass eigentlich was verändert wurde. Das hab ich aber mittlerweile hoffentlich auch im Griff.

 

Ups, das erinnert mich daran, dass ich die Vor-Nachlaufzeiten noch aus dem WebAPI auslesen muss ...