Posts by 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:

bool cStreamdevDevice::SetPid(cPidHandle *Handle, int Type, bool On) {
    Dprintf("SetPid, Pid=%d, Type=%d, On=%d, used=%d\n", Handle->pid, Type, On, Handle->used);

    bool res = true; 
    if (Handle->pid && (On || !Handle->used)) {
        res = m_ClientSocket->SetPid(Handle->pid, On);

        m_Pids += (!res) ? 0 : On ? 1 : -1;
        if (m_Pids < 0) 
            m_Pids = 0;
    }
    return res;
}

Hast du diese Patche integriert?

streamdev-abrt-fix

Deadlock fix

Naja dir sollte bewusst sein, dass du nur die unverschlüsselten Sender schauen kannst. Für alle anderen Sender (Privaten HD Sender bzw. die Sender aus den TV-Zubuch-Paketen) brauchst du zwingend den Telekom-Receiver.

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

Mit entsprechenden Plugin funktioniert das schon, aber das darf hier nicht diskutiert werden

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...

Das Problem ist, dass dem streamdev-Paket aus dem eTobi-Repository ein Patch fehlt. Ohne den klappt das Umschalten ab VDR 2.3.9 auf dem Raspberry Pi nicht mehr.

#include <future>

darf natürlich nicht vergessen werden.

Wenn dann muss es hier so aussehen:

std::async([&globalTimers](){ globalTimers.LoadTimers(); }).get();

Aber auch ungetestet

MfG

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)

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.

Das ist natürlich klar, dass das CAM entschlüsselt. Da hab ich mich etwas unglücklich ausgedrückt.

Ich wollte damit nur sagen, dass der Client nicht an der Entschlüsselung beteiligt ist.

Doch die Octopus Nett entschlüsselt komplett eigenständig. Der Client muss das der Octopus aber durch einen Parameter mitteilen, was so nicht in dem Sat>IP Standard festgelegt ist. Deshalb beherrschen das nicht alle Clients.

Gibt glaube auch eine Android-App von Herrn Hackbart, die das kann.

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

Thread 7 (Thread 0x7f45757de700 (LWP 13324)):
#0  0x00007f45c60783bd in __lll_lock_wait () from /lib64/libpthread.so.0
#1  0x00007f45c6071163 in pthread_mutex_lock () from /lib64/libpthread.so.0
#2  0x0000000000527059 in cMutex::Lock (this=0x1d518d8) at thread.c:224
#3  0x000000000052778f in cMutexLock::Lock (this=0x7f45757dde10, Mutex=<optimized out>) at thread.c:404
#4  0x000000000049152f in cDevice::Action (this=0x1d4efa0) at device.c:1676
#5  0x0000000000527635 in cThread::StartThread (Thread=0x1d4efa0) at thread.c:293
#6  0x00007f45c606e61b in start_thread () from /lib64/libpthread.so.0
#7  0x00007f45c499e91f in clone () from /lib64/libc.so.6

Thread 1 (Thread 0x7f45c66ee740 (LWP 13151)):
#0  0x00007f45c60783bd in __lll_lock_wait () from /lib64/libpthread.so.0
#1  0x00007f45c6071163 in pthread_mutex_lock () from /lib64/libpthread.so.0
#2  0x0000000000527059 in cMutex::Lock (this=0x1d4efc0) at thread.c:224
#3  0x00000000005277f0 in cThread::Lock (this=<optimized out>) at thread.h:94
#4  cThreadLock::Lock (this=0x7ffe9e0eafb0, Thread=<optimized out>) at thread.c:430
#5  0x00007f45b49bd261 in cStreamdevDevice::SetPid (this=0x1d4efa0, Handle=0x1d4f0c8, Type=<optimized out>, On=<optimized out>) at device.c:191
#6  0x000000000048db00 in cDevice::DelPid (this=this@entry=0x1d4efa0, Pid=101, PidType=PidType@entry=cDevice::ptOther) at device.c:622
#7  0x000000000048fde2 in cDevice::Detach (this=<optimized out>, Receiver=Receiver@entry=0x1e364b0) at device.c:1810
#8  0x00000000004ed834 in cReceiver::Detach (this=this@entry=0x1e364b0) at receiver.c:128
#9  0x0000000000534bae in cTransfer::~cTransfer (this=0x1e364b0, __in_chrg=<optimized out>) at transfer.c:22
#10 0x0000000000534dba in cTransfer::~cTransfer (this=0x1e364b0, __in_chrg=<optimized out>) at transfer.c:24
#11 cTransferControl::~cTransferControl (this=0x1cd5d40, __in_chrg=<optimized out>) at transfer.c:72
#12 0x0000000000534df9 in cTransferControl::~cTransferControl (this=0x1cd5d40, __in_chrg=<optimized out>) at transfer.c:73
#13 0x00000000004eafd3 in cControl::Shutdown () at player.c:105
#14 0x0000000000492fa9 in cDevice::SwitchChannel (this=0x1d4c5a0, Channel=0x1cb6bd0, LiveView=LiveView@entry=true) at device.c:787
#15 0x00000000004798bb in cChannels::SwitchTo (this=this@entry=0x7a2aa0 <cChannels::channels>, Number=<optimized out>) at channels.c:1040
#16 0x00000000004c83f8 in cDisplayChannel::ProcessKey (this=0x1e3a490, Key=kDown) at menu.c:4774
#17 0x0000000000472a5f in main (argc=<optimized out>, argv=<optimized out>) at vdr.c:1390

Also sobald der vdr-2.3.8-fixdevicedetachlock-2 Patch von Klaus am Client eingespielt wird, friert der Client sehr häufig ein.

Egal ob ein gepatchtes streamdev verwendet wird oder die ungepatchte Variante von https://projects.vdr-developer…/vdr-plugin-streamdev.git

Als Plugins hatte ich am Client nur den streamdev client und das softhddevice.

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