Wie verhält es sich denn, wenn du die beiden Antennenkabel mal vertauscht?
Klaus
Beiträge von kls
-
-
Dann probier es bitte mal ohne streamdev-server.
Klaus
-
Apr 20 15:27:09 rec18 vdr: [12728] device 1 TS buffer thread started (pid=12709, tid=12728, prio=high)
Kommt nach dieser Zeile gar nichts mehr?
Auch wenn du längere Zeit wartest (einige Minuten)?
Schalte bitte mal "Setup/Miscellaneous/Emergency exit" ein und schau, was dann passiert.
Klaus
-
Poste bitte das komplette Log ab dem Start des VDR, sowie deine setup.conf.
Verwende dabei einen ungepatchten original VDR 2.4.0, mit nur den allernötigsten Plugins.
Klaus
-
@Slartibartfas042: mit diesen Macros werden Arrays angelegt, und da braucht man halt eine konkrete Größe.
ich habe mir für die Zukunft vorgemerkt, dies dynamischer zu handhaben, ohne feste Grenze (soweit möglich). Bis dahin kannst du ja mit den vergrößerten Werten arbeiten.
Warum du mit den gegebenen Werten nur 26 Radiostationen streamen kannst könnte vielleicht an der Verteilung der Stationen auf die Transponder (und damit Devices liegen). Wenn alle auf einem Transponder liegen, dann greift MAXRECEIVERS. Liegen alle auf unterschiedlichen Transpondern, dann greift MAXDEVICES. MAXPIDHANDLES dürfte es wohl eher nicht sein, denn für einen Radio-Kanal braucht man ja nur *eine* PID.
Klaus
-
Der Patch ftp://ftp.tvdr.de/vdr/Develope…x-svdrp-modt-recflag.diff behebt einen Fehler in der Handhabung des tfRecording-Flags bei den SVRP-Befehlen MODT und UPDT.
Das tfRecording-Flag darf nur von dem VDR modifiziert werden, auf dem der Timer gespeichert ist und aufnimmt.
Klaus -
Ich habe unter ftp://ftp.tvdr.de/vdr/Developer/Patches/vdr-2.4 ein Verzeichnis angelegt, in dem ich Bugfixes sammeln werde, die nach der Freigabe der stabilen Version 2.4.0 aufgetreten sind. Die Dateinamen werde ich so wählen, dass man die Patches in alphabetischer Reihenfolge anwenden kann, womit Probleme vermieden werden, sollten zwei Patches an der gleichen Stelle Veränderungen vornehmen. Zu gegebener Zeit werde ich evtl. eine Version 2.4.1 freigeben.
Dies soll ein reiner Ankündigungsthread bleiben, daher etwaige Erfahrungs- oder Problemberichte bitte in separten Threads machen, am besten mit dem Dateinamen des betreffenen Patches im Titel.
Klaus
-
Die Zuordnung steht in der diseqc.conf:
S19.2E 11700 H 9750 t V W10 S2 [E0 10 5A 00 00] W10 v
VDR sucht sich in der diseqc.conf die Zeile für den gewünschten Satelliten, Frequenzband und Polarisation, und der S-Wert (hier 2) gibt dann dem SCR-Gerät an, was es empfangen soll.
Klaus
-
Ich hatte eigentlich gedacht, dass ich das schon vor Jahren an den Autor geschickt hätte:
Alles anzeigenDiff- --- dvbhdffdevice.c 2015-12-09 18:28:32.000000000 +0100
- +++ dvbhdffdevice.c 2016-12-06 12:50:50.000000000 +0100
- @@ -461,7 +461,8 @@
- const tTrackId *TrackId = GetTrack(Type);
- if (TrackId && TrackId->id) {
- int streamType = 0;
- - cChannel * channel = Channels.GetByNumber(CurrentChannel());
- + LOCK_CHANNELS_READ;
- + const cChannel * channel = Channels->GetByNumber(CurrentChannel());
- if (channel) {
- if (IS_AUDIO_TRACK(Type))
- streamType = channel->Atype(Type - ttAudioFirst);
Klaus
-
Es ist allerdings eine "stable", keine "developer" Version ;-).
Dennoch viel Spaß damit!
Klaus
-
Was wäre die Freigabe einer stabilen Version ohne einen "last minute patch"!?
Mir wurde berichtet, dass bei der Wiedergabe mit aktiver Fortschrittsanzeige die CPU-Last recht hoch ist im Vergleich zur Version 2.2.0. Der beiliegende Patch sorgt dafür, dass die Anzeige nicht öfter als alle 100ms aufgefrischt wird. Das reduziert die CPU-Last hier bei mir deutlich, und ich kann keine negativen Seiteneffekte erkennen.
Bitte testet diesen Patch intensiv und gebt mir (gerne auch hier in diesem Thread) eine Rückmeldung. Falls ich bis morgen Mittag nicht mindestens 5 positive Rückmeldungen (und keine einzige negative) bekommen habe, dann werde ich diesen Patch nicht in die stable 2.4.0 aufnehmen. Das Risiko, im letzten Moment noch was kaputtzumachen, wäre dann zu groß.
Bitte berichtet auch, ob sich dadurch bei euch wirklich eine Reduzierung der CPU-Last bei geöffneter Fortschrittsanzeige ergibt. Also bitte erstmal ohne Patch messen, und dann mit.
Klaus
-
Für die Optik gibt es ja die Plugin-Schnittstelle - wenn der Autor eines Plugins dieses nicht mehr pflegen will, dann ist das seine Sache und nicht meine Schuld. Was "kein GIT" mit der Plugin-Entwicklung zu tun hat erschließt sich mir nicht.
Klaus
-
Ohne Skindesigner ist vdr optisch so ziemlich 90er-mässig.
Erst mit skindesigner wird daraus was anständiges.
Kommt halt immer darauf an, wozu man es benutzt ;-).
Als Video-Spiel ist es echt etwas eintönig, da hast du recht. Ich nehme es daher eigentlich nur zum Aufnehmen und Wiedergeben von TV-Sendungen her ;-).
Klaus
-
Code
This function is called to set the current channel. Of course the caller has a lock on the Channels list, because it hands over a pointer to a cChannel. Since at this time the Channels are locked, this function can't lock the Timers, because those would have to be locked before the channels in order to avoid a possible deadlock.
If a skin wants to display timer related things in its channel display, it can do so in its Flush() function, which is called without holding any locks on global lists.
Klaus
-
This is skindesigner's fault. The channel display has no business setting a lock on the Timers - at least not in the SetChannel() function.
Klaus
-
Das wäre das hier:
Alles anzeigenDiff- --- device.c 2017/05/30 11:06:11 4.23
- +++ device.c 2018/01/27 14:45:08 4.26
- @@ -120,6 +120,7 @@
- delete dvbSubtitleConverter;
- if (this == primaryDevice)
- primaryDevice = NULL;
- + Cancel(3);
- }
- bool cDevice::WaitForAllDevicesReady(int Timeout)
- @@ -1673,6 +1674,7 @@
- int Pid = TsPid(b);
- bool IsScrambled = TsIsScrambled(b);
- for (int i = 0; i < MAXRECEIVERS; i++) {
- + cMutexLock MutexLock(&mutexReceiver);
- cReceiver *Receiver = receiver[i];
- if (Receiver && Receiver->WantsPid(Pid)) {
- Receiver->Receive(b, TS_SIZE);
- @@ -1768,10 +1770,8 @@
- }
- }
- Receiver->Activate(true);
- - Lock();
- Receiver->device = this;
- receiver[i] = Receiver;
- - Unlock();
- if (camSlot && Receiver->priority > MINPRIORITY) { // priority check to avoid an infinite loop with the CAM slot's caPidReceiver
- camSlot->StartDecrypting();
- if (camSlot->WantsTsData()) {
- @@ -1801,13 +1801,11 @@
- if (!Receiver || Receiver->device != this)
- return;
- bool receiversLeft = false;
- - cMutexLock MutexLock(&mutexReceiver);
- + mutexReceiver.Lock();
- for (int i = 0; i < MAXRECEIVERS; i++) {
- if (receiver[i] == Receiver) {
- - Lock();
- receiver[i] = NULL;
- Receiver->device = NULL;
- - Unlock();
- Receiver->Activate(false);
- for (int n = 0; n < Receiver->numPids; n++)
- DelPid(Receiver->pids[n]);
- @@ -1815,6 +1813,7 @@
- else if (receiver[i])
- receiversLeft = true;
- }
- + mutexReceiver.Unlock();
- if (camSlot) {
- if (Receiver->priority > MINPRIORITY) { // priority check to avoid an infinite loop with the CAM slot's caPidReceiver
- camSlot->StartDecrypting();
Evtl. musst du es von Hand einpflegen, weil sich auch einiges anderes geändert hat.
Klaus
-
Ich habe das mal mit "plain vanilla" VDR 2.3.9 probiert, konnte aber kein Problem feststellen.
Allerdings benutze ich weder streamdev noch epg2vdr. Als Client benutze ich zur Zeit einen Raspberry Pi.
Klaus
-
Hätte mich ja schon mal interessiert wie Klaus dazu steht und welche Priorität das Thema hat.
Ich selber brauche keine Favoritenliste, ich benutze einfach die channels.conf ;-).
Aber ich sehe natürlich den Bedarf und möchte nach der Version 2.4.0 etwas in der Richtung machen.
Klaus
-
Ich möchte jetzt erstmal die Version 2.4.0 festklopfen, danach komme ich evtl. auf das Eingangsthema zurück.
Klaus
-
Das dürfte der Fehler sein, der in VDR 2.3.9 unter "Fixed a possible crash when stopping VDR" behoben wurde.
Klaus
