Ob Du es selbst brauchst ist doch unerheblich!

Du musst das sportlich sehen!

Was muss man sich denn alles aneignen (Programmiersprache etc.) um überhaupt zu verstehen, was da in der Box so vor sich geht?

Linuxkenntnisse sind vorhanden!

Hallo,

momentan arbeite ich an einem VPS-Plugin.
Technisch sieht das so aus, dass ein Hintergrundprogramm Änderungen am Running-Status einer Sendung an das Plugin meldet.

Das Plugin funktioniert bereits. Ich will aber erstmal noch ein paar Tests durchführen, bis ich das Plugin vorstelle.

Hallo sftg,

Soll das Plugin das digitale VPS-Signal auswerten können? Das wäre natürlich prima.

Vielleicht müßte sich mal ein Dev bei Reel einschleichen um zu sehen was da programmiert ist und dann gleich noch die automatische Werbeerkennung mitbringen...

Zitat von sftg

Hallo,

momentan arbeite ich an einem VPS-Plugin.
Technisch sieht das so aus, dass ein Hintergrundprogramm Änderungen am Running-Status einer Sendung an das Plugin meldet.

Das Plugin funktioniert bereits. Ich will aber erstmal noch ein paar Tests durchführen, bis ich das Plugin vorstelle.

also gehst du nicht auf den pdc descriptor los sondern nur auf den running status? aja running status muss nicht bei jedem sender richtig gesetzt werden, dass habe ich schon mal rausgefunden

verwendest du die event-id auch irgendwie bei den aufnahmen?! oder weiß jemand ob die eventid bei irgendwelchen aufnahmen als verweis oder so verwendet wird?

Der PDC-Descriptor wird auch unterstützt. Bei manuellen Timer-Programmierungen kann die VPS/PDC-Zeit angegeben werden und das Plugin ermittelt damit die Event-ID.
Bei Programmierungen über den EPG liegt die Event-ID im Timer schon vor.

wie meinst du das mit den manuellen aufnahmen, dass hier die vps zeit eingegeben werden kann? darf man erfahren wie du da dann alles mit der logik machst? weil das vps signal bekommst ja dann nicht mehr über dvb-s

und wie handelts event ids die gleich sind? zb. heute am orf2e hat die doppelsendung "Infos und tipps" die gleiche eventid (utc 16:45:10 und 16:51:00)

das ist mir schon klar, nur bin ich mir nicht sicher ob vps zeit auch IMMER die im pdc stehende zeit ist.

kann bitte schnell wer nachschauen auf der dream, was auf orf2_europe heute zw. 18:50 und 19:00 läuft, weil ich habe hier auch ein selbstgebasteltes epg plugin und mir zeigt es hier zb. folgendes an:
05.05.2011 - 16:48:10 (utc) Infos und tipps (pdc = 05.05. 18:51)
05.05.2011 - 16:51:10 (utc) Infos und tipps (pdc = 05.05. 18:51)

laut tv.orf.at sollte dies nicht so sein, da wäre die zweite sendung eigentlich "BUNDESLAND HEUTE SERVICE" und hat auch kein vps

und nun zu dem was ich vorher gepostet habe: was ist wenn biede die gleiche eventid haben (jaja ich weiß eh, dass dies nicht so sein darf, ist aber so, jedenfalls bei mir?!) und in diesem fall auch den gleichen pdc wert?

war nur ne blöde spielerei mit einer dvb-s karte die außerhalb läuft und wo ich mir selbst einen epg parser gebastelt habe deshalb auch die frage ob wer auf der dream die sache mit eventid und sendungsnamen überprüfen könnte (weil auf die box komme ich gerade nicht), nicht das ich einen fehler habe bei meiner abarbeitung.

aja weils mir gerade auch noch einfällt bzgl. der eventid ist sowieso der orf der große hammer, weil da ist es sogar relativ oft so, dass eventids doppelt vorkommen.

Zitat von Reichi

Danach fehlt dann "nur noch" eine entsprechende Prüfung beim Start eines Timers ob auch tatsächlich das Event mit der programmierten EventID aufgenommen wird oder ob sich dieses verschoben hat.
Ein echte Herausforderung sind dabei eventuell manuell ergänzte Vorlaufzeiten... das kann bei kürzeren Sendungen dazu führen dass man nicht mehr sicher sagen kann welches Event das eigtl ist ;).

Eine weitere Herausforderung sehe ich darin, wie man an den Descriptor kommen will, wenn man nicht auf dem Sender/Transponder steht.
Also, ich programmiere das Sport Studio Samstag abends, aber der olle Gottschalk überzieht mal wieder....Jedoch schaue ich zu dieser Zeit einen ganz anderen Kanal auf einem anderen Transponder....wie soll denn bitte dann das Plugin nun den Descriptor empfangen? Fällt mir nur ein, dass die Box dann umschalten muss...aber das will ich natürlich nicht, denn ich habe ja 2 Tuner, und das Sport Studio soll gefälligst auf dem anderen Tuner aufgenommen werden...

Aber ich bin gespannt wie ein Flitzebogen, wie sftg das lösen wird...

Zitat von Reichi

Kurze Frage: Woher kriegt das Plugin den PDC-Wert? oder läuft das außerhalb von e2?

Ja, läuft außerhalb.
Btw: Dabei habe ich mal eine Frage. Die mipsel-linux-g++ erzeugt eine 72 KB Datei, die aber zu 85% mit Nullbytes gefüllt ist. Hast du dafür eine Erklärung?
Bei der mipsel-oe-linux-g++ (Openembedded 1.6) ist die Binary nur 11 KB groß. Da das Programm aber bei den Images mit OE 1.5 nicht lauffähig ist, will ich lieber zur mipsel-linux-g++ greifen.

Zitat von Dr.Best

Jedoch schaue ich zu dieser Zeit einen ganz anderen Kanal auf einem anderen Transponder....wie soll denn bitte dann das Plugin nun den Descriptor empfangen?

Kommt drauf an, welchen Sender man schaut. Bei ARD/ZDF kann der EPG (d.h. Present/Following inkl. PDC-Descriptor) aller ÖR-Sender auf allen Transpondern von ARD/ZDF empfangen werden.

Zitat von Dr.Best

Fällt mir nur ein, dass die Box dann umschalten muss...aber das will ich natürlich nicht, denn ich habe ja 2 Tuner, und das Sport Studio soll gefälligst auf dem anderen Tuner aufgenommen werden...

Wenn der andere Tuner frei ist, dann holt sich das Plugin den Tuner (indem eine Aufnahme-Simulation gestartet wird).

aja, könnte mir jemand die sinnhaftigkeit der sender-localtime angabe im pdc descriptor erklären oder ist das gar nicht sicher ob das immer localtime ist?

Zitat von Ghost

oeh genau diese Sinnlosigkeit mit localtimes hat mich "damals" dazu veranlasst den ganzen krempel ad acta zu legen

Ist aber schon recht lange her. Ich versteh nicht, wieso man extra so einen "schrott wie PDC" einführen muss, wenn es eigentlich mit den EIT running states eine tolle Lösung gäbe.

Der PDC-Descriptor steuert nicht die Aufnahme, der dient nur zur Identifizierung.
Wenn man für längere Zeit im Voraus eine Sendung aufnehmen will (d.h. die Sendung wird noch nicht im EPG angegeben), dann braucht der Receiver ein anderes Identifizierungsmerkmal als die Event-ID, die ja bei einer manuellen Timer-Programmierung nicht bekannt ist. Deswegen gibt man hier die geplante Startzeit der Sendung an.

Ich verstehe auch nicht, was ihr nun unbedingt gegen localtime habt. Da das ein reiner Identifikator ist, wäre es doch sogar eher unvorteilhaft, wenn an einem Identifikator auch noch rumgerechnet werden müsste.

Interessant finde ich noch, dass ARD/ZDF zwei Descriptor haben, in denen die geplante Startzeit (in localtime) angegeben wird.

DVB-DescriptorTag: 105 (0x69)  [= PDC_descriptor]
descriptor_length: 3 (0x03)
reserved: 15 (0x0f)
Programme_identification_label: 0x62b00 [= month=5  day=12   hour=12  min=0]


DVB-DescriptorTag: 130 (0x82)  [= User defined/ATSC reserved]
descriptor_length: 13 (0x0d)
Descriptor-data:
0000:  31 32 3a 30 30 31 32 2e  30 35 23 30 30            12:0012.05#00

Weiß jemand, inwiefern der zweite Descriptor (der offenbar nicht standardisiert ist?) verwendet wird?

Zitat von Reichi

Die ETSI sagt leider nicht wirklich was darüber ob das nun localtime ist oder nicht (siehe http://broadcasting.ru/pdf-standard-spec…0468.v1.5.1.pdf Seite 57). Den Codestücken aus dem Netz zu Folge scheint das aber überall so zu sein.

In der ETSI EN 300 231 findet sich noch was:

Zitat

The PIL parameter normally carries the local announced broadcast time (day, month, hour, minute) identifying the transmitted programme.

Zitat von sftg

Der PDC-Descriptor steuert nicht die Aufnahme, der dient nur zur Identifizierung.
Wenn man für längere Zeit im Voraus eine Sendung aufnehmen will (d.h. die Sendung wird noch nicht im EPG angegeben), dann braucht der Receiver ein anderes Identifizierungsmerkmal als die Event-ID, die ja bei einer manuellen Timer-Programmierung nicht bekannt ist. Deswegen gibt man hier die geplante Startzeit der Sendung an.

so und nun wird es spannend: eine tv-zeitschrift hat eine vps zeit von 12:00 uhr, der sendungsbeginn ist in der zeitschrift mit 12:05 abgedruckt, wie sieht dann die pdc zeit aus? 12:00 oder kann die auch 12:03 sein?
in etsi 300468 v1.9.1 steht ja folgendes "The PIL contains date and time of the first published start time of a certain event"
ähm geht man hier vom epg aus oder überhaupt die erstmalige planung des events, wird hier nur auf epg das ganze bezogen könnten vps und pdc unterschiedlich sein ...

du schreibst ja auch, dass du sonst total auf die event-id gehst, wie löst du das problem der doppelten event-ids? die sind ja nicht unüblich wie ich schon geschildert habe
Ghost hat du dir zu diesem thema damals was überlegt?!

Zitat von sftg

Ich verstehe auch nicht, was ihr nun unbedingt gegen localtime habt. Da das ein reiner Identifikator ist, wäre es doch sogar eher unvorteilhaft, wenn an einem Identifikator auch noch rumgerechnet werden müsste.

da alles ander ja in utc angegeben wird, muss man hier nun aufpassen in welcher zeitzone man sich befindet und nein nicht wo man sich selbst befindet, sondern in welcher zeitzone sich der sender befindet! und ob die sendung schon in der sommerzeit ist oder noch nicht bzw. ob die vps zeit in der sommerzeit ist usw.
erzeugt lauter blöde abhängigkeiten und fehler!

Zitat von sftg

Interessant finde ich noch, dass ARD/ZDF zwei Descriptor haben, in denen die geplante Startzeit (in localtime) angegeben wird.

Code

DVB-DescriptorTag: 105 (0x69) [= PDC_descriptor]
descriptor_length: 3 (0x03)
reserved: 15 (0x0f)
Programme_identification_label: 0x62b00 [= month=5 day=12 hour=12 min=0]


DVB-DescriptorTag: 130 (0x82) [= User defined/ATSC reserved]
descriptor_length: 13 (0x0d)
Descriptor-data:
0000: 31 32 3a 30 30 31 32 2e 30 35 23 30 30 12:0012.05#00

Weiß jemand, inwiefern der zweite Descriptor (der offenbar nicht standardisiert ist?) verwendet wird?

ja das wäre auch interessant