Beiträge von nanohcv

    Zur Jugendschutz-PIN kann ich noch folgendes ergänzen. Die PIN-Abfrage basiert ausschließlich auf der EIT (EPG) im MPEG-Transportstrom. Fehlt die EIT im Stream, kommt die PIN-Abfrage bei jedem Senderwechsel. Ist die EIT mit Jugendschutzinformationen vorhanden, kommt die PIN-Abfrage nur bei Sendungen mit der Altersfreigabe ab 16 oder 18.

    Um die PIN-Abfrage zu umgehen leitet VDR nicht die originale EIT zum Modul sondern nach jedem Senderwechsel für eine kurze Zeit ein Grundgerüst (ohne Jugendschutzinformationen) einer EIT zum Modul. Damit wird dem CAM vorgegaukelt, dass die Sendung für alle Altersklassen freigegeben ist und eine PIN-Abfrage nicht erforderlich ist.


    Verwendet man aber Plugins wie VNSI oder Streamdev gibt es ein Problem, denn diese Plugins müssen ja den Stream von einem Device abrufen. Das tun diese Plugins unter anderem in ihren Ableitungen der cReceiver Klasse. In der cReceiver Klasse gibt man an anhand der PIDs an, welche Daten man aus dem Stream abrufen möchte. Das Problem an der Sache ist, dass alles was dort angegeben wird auch beim CAM landet und da diese Plugins i.d.R alle PIDs eines Kanals, also auch die PID 18 der EIT, dort abrufen, kann es wieder zur PIN-Abfrage kommen, denn jetzt bekommt das CAM einmal die Fake-EIT vom VDR und einmal die originale aus dem MPEG-Stream. Und da die Fake-EIT vom VDR nur kurz injected wird, kommt es zumindest bei Sendungen mit Altersfreigabe wieder zur PIN-Abfrage.


    D.h. entweder man lebt mit dem Workaround mit der camresponses.conf und hat längere Umschaltzeiten oder jemand erbarmt sich und passt das VNSI-Plugin an und verhindert dort, dass die PID 18 in der cReceiver Klasse abgerufen wird. Auswirkungen sollte es vermutlich keine haben, da das VNSI-Plugin das EPG nicht selbst aus dem MPEG-Stream extrahiert sondern dafür die VDR-API nutzt.

    Also im git ist keiner von beiden, gerade nochmal kontrolliert.

    Schau lieber beim Deadlock-Fix genau hin, weil auf den kommt es an :)

    Wichtig ist hier, dass die Zeile auskommentiert bzw. gelöscht wird.


    So muss es aussehen:

    Ist denn das DVB-T2 SimpliTV-Modul auch ein CI+ Modul? Denn bei CI+ laufen doch so ein paar Sachen anders.

    Z.B. wird der TS-Stream ja nach der Entschlüsselung vom Modul wieder verschlüsselt um dann letztendlich von VDR-Plugin wieder entschlüsselt zu werden. Keine Ahnung, ob das überhaupt so mit mehreren Streams funktioniert.


    Jedenfalls gibt es den Multistream-Support bei CI+ erst ab der CI+ Version 1.4 und da auch nur optional.

    Und weder das Sky-Modul noch das VDR-Plugin beherrschen den CI+ 1.4 Standard

    Ich hatte mal ein ASrock j4205-itx damit war die V7A auch nicht stabil zum laufen zu bringen. Hab mir dann die Octopus MiniPCIe Bridge mit Duoflex V4a geholt und mit einem M.2 auf MiniPCIe Adapter an dem M.2 Slot, der eigentlich für Wlan Module da ist, betrieben. Das lief ohne Probleme

    Mit dem SDK für die Samsung TVs mit Tizen habe ich schon beschäftigt. Ich hab auch schon paar kleine kleine Testapps geschrieben, um auszuloten was alles so möglich ist. Man ist aber auf die Api's angewiesen, die Samsung da bietet, denn obwohl Tizen auf Linux basiert, hat man auf das System keinen Zugriff.


    Meine Idee war ein Ausgabedevice zu schreiben, was mit der NaCl Api auch möglich wäre.

    Es gibt aber ein Haken, weshalb ich da noch nicht weiter gemacht habe. Die einzigen Möglichkeiten so eine App auf den TV zu installieren, ist der App Store oder über die Entwicklungsumgebung "Tizen-Studio". Die letzte Variante ist ziemlich kompliziert und hat auch den Haken, dass die Apps dann nicht dauerhaft auf dem Fernseher bleiben. Nach einer gewissen Zeit, werden die Apps wieder gelöscht.


    Man müsste also so eine App bei Samsung einreichen und hier ist auch schon das nächste Problem. Nur der US-App-Store ist relativ offen. Um eine App z.B. in den deutschen Store zu bekommen, muss man mit Samsung ein Partner-Vertrag abschliessen. Ob das was kostet bzw. ob das überhaupt für private Entwickler möglich ist, konnte ich noch nicht in Erfahrung bringen.


    Man könnte zwar seinen Fernseher auf den US-Store umstellen, aber dann kann man auch nur die US-Varianten von Netflix usw. verwenden. Solche Apps wie die ZDF-Mediathek gibt es im US-Store z.B. gar nicht. Man kann auch nicht irgendwelche Apps aus dem deutschen Store installieren und dann auf den US-Store umstellen, da der Wechsel der Stores immer mit einem Werkseinstellung-Reset verbunden ist :)


    Also alles nicht so einfach bei Samsung...

    Ich hatte mit SkinFlatPlus auch den einen oder anderen Deadlock. Das Problem war da das gleiche, dass die aktiven Timer irgendwo in SetChannel abgerufen wurden. Ich habe das Timer-Holen dann einfach in einem seperaten Thread ausgelagert.


    Für Skindesigner würde das dann so ausssehen (Achtung, das ist ein völlig ungetesteter Patch, der nur zeigt, wie ich das ungefair bei SkinFlatPlus gemacht habe)


    locking-fix.diff

    Es gab ja schon mal ein Problem mit einem Patch für vdr-2.3.8 und streamdev. (Wo das Raspberry Pi auch besonders anfällig für war)

    Streamdev Client/Server + CI Modul = Glückspiel ?


    Da hat Klaus mir den Tip gegeben im Streamdev client (/client/device.c)


    Code
    LOCK_THREAD;

    in cStreamdevDevice::SetPid() auszukommentieren, was auch geholfen hat


    Vielleicht liegt hier das Problem in "void cStreamdevDevice::CloseDvr(void)"

    Du müsstest dein VDR so absichern, dass es die ganzen Einschränkungen von CI+ implementiert (Timeshift-, Aufnahmebeschränkungen usw.)

    Dann musst du dein System so absichern, dass niemand drin herum basteln kann (dich quasi aus deinem VDR aussperren) und anschließend dein PC zertifizieren lassen, was ca. 10000€ kostet.

    Das zertifizieren wird auch niemand übernehmen können, da immer das Gesamtsystem zertifiziert werden muss. Software alleine geht nicht ;)


    Folglich wird es nie legal gehen.

    Hier noch der Backtrace der 2 Threads die anscheinend den Deadlock verursachen:

    Als ich an den streamdev Problem gearbeitet habe, hatte ich auch immer ein vanilla-vdr 2.3.8 verwendet.


    Bei den MLD Leuten gibt es wohl auch das Problem, welches Frodo hier beschreibt.

    Die haben wohl auch eine ganze Reihe vdr-Patche integriert, wenn ich das richtig sehe. Kann schon sein, dass es daran liegt.


    Das sich der Server manchmal aufhängt, kann schon an dem "cDevice::Detach() blockiert" Problem liegen, wofür Klaus ein Patch bereit gestellt hat.

    Da sich der Server bei mir bis jetzt noch nicht aufgehangen hat und der Patch von Klaus bei mir irgendwie vorbei gegangen ist, habe ich es damit natürlich nie getestet ;)