Beiträge von nanohcv

    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
    1. 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 ;-)

    Noch eine kleine Erläuterung zum Problem.


    Der Client schickt unter VDR 2.3.x unter bestimmten Umständen beim Kanalwechsel erst das TUNE Command und dann das ABRT Command.

    Richtig wäre erst das ABRT Command senden und dann mit TUNE auf den neuen Kanal wechseln.

    Die falsche Reihenfolge führt beim Server dann dazu, dass die Pid Receiver nach dem Attach gleich wieder detached werden, wodurch die CAM-Zuordnung flöten geht.

    Danach werden die Receiver zwar wieder angehangen, weshalb es bei FTA Channels (außer neben etwas längeren Umschlaltzeiten) keine Probleme gibt, aber ein Cam wird nicht mehr zugeordnet => Folglich bleibts beim Client düster.


    Da es gewünscht wurde, den Fix nochmal als Patch zur Verfügung zu stellen, habe ich den hier angehangen.

    Der Patch enthält auch Zabrimus's ChannelChange Patch, den ich nur (wegen MTD) an die aktuelle VDR Version angepasst habe.

    Hallo,


    so bei Fedora gabs nun ein Kernel-Update auf 4.14.

    Seitdem funktioniert mein FlexCI nicht mehr.


    Mit 4.13 und dddvb 0.9.32 funktioniert es noch...


    Unter 4.13 und dem aktuellen dddvb git (87246de124e4a7939dee4b4b71248a52c9c6893) geht es aber auch nicht mehr.

    Hast du unter 2.2 auch das Plugin aus dem dev Branch gebaut?


    Falls nicht, dann mal unter 2.3 die config files neu erstellen lassen.

    Das geht wie folgt:

    - xmlapi.conf und die ini Dateien aus /var/lib/vdr/plugins/xmlapi löschen

    - vdr neustarten damit die Dateien neu erstellt werden

    - ggf. config Dateien nach den eigenen Bedürfnissen anpassen

    - in der xmlapi.conf folgendes setzen:

    Code
    1. RelativeLogoUrl=0

    - vdr nochmal neustarten