[ANNOUNCE] VDR developer version 2.3.3

Jansen · 28. März 2017

Zitat

VDR developer version 2.3.3 is now available at

ftp://ftp.tvdr.de/vdr/Developer/vdr-2.3.3.tar.bz2

A 'diff' against the previous version is available at

ftp://ftp.tvdr.de/vdr/Developer/vdr-2.3.2-2.3.3.diff

MD5 checksums:

73182b570bcf5a67ab56f7734e479631 vdr-2.3.3.tar.bz2
112c2057dbd7e86c31f8227f61cfd2a6 vdr-2.3.2-2.3.3.diff

WARNING:
========

This is a *developer* version. Even though *I* use it in my productive
environment, I strongly recommend that you only use it under controlled
conditions and for testing and debugging.

The changes since version 2.3.2:

- Added 'S3W ABS-3A' to sources.conf (thanks to Frank Richter).
- Fixed a possible deadlock in the recordings handler thread.
- Updated the Russian OSD texts (thanks to Andrey Pridvorov).
- Added a missing dependency to the Makefile to avoid error messages in the
clean-plugins target (thanks to Tobias Grimm).
- The channel/CAM relations (i.e. the information which CAM can decrypt a given
channel) are now stored in the file 'cam.data' in the cache directory (suggested
by Dietmar Spingler). This speeds up switching to encrypted channels after
newly starting VDR, in case there is more than one CAM in the system.
- Fixed a flaw in handling timeouts for encrypted channels.
- The mechanism of trying different CAMs when switching to an encrypted channel is
now only triggered if there acually is more than one CAM in the system.
- Fixed updating the elapsed/remaining time in the progress display during fast
forward/rewind.
- Changed 'unsigned' to 'signed' in some places to avoid trouble with abs() in
gcc6+ (reported by Derek Kelly).
- CAMs that can handle multiple devices at the same time can now indicate this
by creating the first cCamSlot as usual, and every other cCamSlot by giving
it the first one as its "MasterSlot". To VDR this means that when searching
for a CAM that can decrypt a particular channel, it only needs to ask the
master CAM slot whether it is suitable for decrypting, and can skip all the
other slots belonging to the same master. This can greatly speed up channel
switching on systems with more than one CAM (that can handle multiple devices).
- The LCARS skin now displays the master CAM's number when a device is tuned to
an encrypted channel.
- The Setup/CAM menu now only displays master CAMs.
- Fixed setting the local machine's SVDRP host name (was overwritten if setup.conf
contained an empty string).
- PIDs can now be added to and deleted from a cReceiver while it is attached to
a cDevice, without having to detach it first and re-attach it afterwards.
- Implemented support for MTD ("Multi Transponder Decryption"). This allows a CAM
that is capable of decrypting more than one channel ("Multi Channel Decryption")
to decrypt channels from different transponders. See the remarks in mtd.h on
what a derived cCamSlot class needs to do in order to activate MTD (thanks to
Jasmin Jessich for writing the ddci2 plugin and for valuable input and help
with testing and debugging).
- The function cRingBufferLinear::Clear() can now be called safely from the
reading thread, without additional locking.
- Now stopping any ongoing recordings before stopping the plugins, to avoid
a crash when stopping VDR while recording.

Have fun!

Klaus

Alles anzeigen

jsffm · 28. März 2017

Läuft bei mir auf vdr2, Installation problemlos.

Danke an Klaus.

9000H · 28. März 2017

Hi,

WOW

Danke Klaus

speed · 28. März 2017

Öhhh ist heute Sonntag ??

3PO · 28. März 2017

Ganz besonders interessant finde ich folgende Meldungen im Log:

Code

Mar 28 20:37:24 [vdr] [7507] CAM 1: replies to QUERY - multi channel decryption (MCD) possible
Mar 28 20:37:24 [vdr] [7507] CAM 1: supports multi transponder decryption (MTD)
Mar 28 20:37:24 [vdr] [7507] CAM 1: activating MTD support
....
Mar 28 20:47:24 [vdr] [7075] switching to channel 136 (Discovery HD)
Mar 28 20:47:24 [vdr] [7075] CAM 1: unassigned from device 1
Mar 28 20:47:24 [vdr] [7075] CAM 1/1: reusing MTD CAM slot
Mar 28 20:47:24 [vdr] [9635] device 1 receiver thread ended (pid=7075, tid=9635)
Mar 28 20:47:24 [vdr] [7075] CAM 1: assigned to device 1
Mar 28 20:47:24 [vdr] [9642] device 1 receiver thread started (pid=7075, tid=9642, prio=high)
Mar 28 20:47:24 [vdr] [9643] device 1 TS buffer thread started (pid=7075, tid=9643, prio=high)
Mar 28 20:47:24 [vdr] [7075] CAM 1: known to decrypt channel S19.2E-133-6-130 (scramblingTimeout = 30s)

Alles anzeigen

Aber irgendetwas scheint sich im handling der Fernbedienung geändert zu haben, denn auf einmal kommen alle Befehle doppelt an?

Wenn z.B "1" drücke, wird auf Kanal "11" geschaltet.

3PO · 28. März 2017

Zitat von 3PO

[] Aber irgendetwas scheint sich im handling der Fernbedienung geändert zu haben, denn auf einmal kommen alle Befehle doppelt an?

Wenn z.B "1" drücke, wird auf Kanal "11" geschaltet.

[ERLEDIGT]

Das war ein typischer Layer 8 Fehler.

carel · 29. März 2017

Hi 3PO,

Off topic:
Wie hast du das erledigt, war das vielleicht der Zapcockpit patch?
Das bewirkt bei mir genau dieses verhalten

Danke,

Carel

3PO · 29. März 2017

Zitat von carel

[...] war das vielleicht der Zapcockpit patch? ...l

Nein, diesen Patch habe und hatte ich nie installiert.

hgutmann · 29. März 2017

MTD/MCD: Nice!

fnu · 29. März 2017

Vielen Dank Klaus fuer Deine Muehen.

Gruss
Frank

anbr · 3. April 2017

Hi,

ich benötige mal eine Bestätigung ob es nur bei mir auftritt oder ein generelles Problem ist.

Wenn ich während der Wiedergabe einer Aufnahme, eine weitere Wiedergabe per SVDRP starte, hängt VDR 2.3.3 in einem Deadlock und ist nicht mehr bedienbar nur ein kill -9 `pidof vdr` beendet die Situation.

Zum Reproduzieren Aufnahmeliste abrufen

Code

svdrpsend LSTR | grep "\-816"
250-816 29.12.08 22:17 2:06  Action~Batman~Batman Begins

Wiedergabe starten (hier z.B. Aufnahme 816)

Code

svdrpsend PLAY 816
220 io SVDRP VideoDiskRecorder 2.3.3; Mon Apr  3 17:05:15 2017; UTF-8
250 Playing recording "816" [29.12.08 22:17  Action~Batman~Batman Begins]
221 io closing connection

Wiedergabe restarten, Connect ist noch erfolgreich, die erste Wiedergabe läuft zwar weiter, aber ist der VDR tot

Code

svdrpsend PLAY 816
220 io SVDRP VideoDiskRecorder 2.3.3; Mon Apr  3 17:05:57 2017; UTF-8
timeout

Jeder weitere Verbindungsversuch, schlägt fehl...

Code

svdrpsend PLAY 816
timeout

Danke,
Andreas

seahawk1986 · 3. April 2017

Ja, das kann ich hier nachvollziehen.

3PO · 3. April 2017

Zitat von seahawk1986

Ja, das kann ich hier nachvollziehen.

Ich nicht.

Bei mir funktioniert es so wie es solll:

Code

vdr01_64 ~ # svdrpsend LSTR |tail -n 2
250 353 26.03.17 10:40 0:58* Terra X: Deutschland von unten: Land (1/2)~Doku (D 2014)
221 vdr01_64 closing connection
vdr01_64 ~ #

Code

vdr01_64 ~ # svdrpsend PLAY 353
220 vdr01_64 SVDRP VideoDiskRecorder 2.3.3; Mon Apr  3 17:35:41 2017; UTF-8
250 Playing recording "353" [26.03.17 10:40  Terra X: Deutschland von unten: Land (1/2)~Doku (D 2014)]
221 vdr01_64 closing connection
vdr01_64 ~ #

kls · 3. April 2017

Ich kann es nachvollziehen und werde debuggen...

Klaus

anbr · 3. April 2017

Hi,

Aufgrund des Feedback habe ich auch schon weitergesucht, und mir auch eine Debugfunktion eingebaut, das Problem liegt wohl bei cResumeFile::Save was auch eine LOCK_RECORDINGS_WRITE innerhalb des LOCK_RECORDINGS_READ anfordert...

Liste alle LOCK_RECORDINGS bei Debuglauf
HasChanged (videodir.c, line 213)
CmdLSTR (svdrp.c, line 1685)
CmdLSTR (svdrp.c, line 1685)
CmdPLAY (svdrp.c, line 2056)
SetTrackDescriptions (menu.c, line 4471)
CmdLSTR (svdrp.c, line 1685)
CmdPLAY (svdrp.c, line 2056)
Save (recording.c, line 318)

Edit: der Aufruf von CmdPLAY erfolgt aber ohne "option"...

Backtrace des Deadlocks

Code

Thread 18 (Thread 0x7f46686d8700 (LWP 7213)):
#0  0x00007f46a0484440 in __pthread_rwlock_wrlock_slow () from /lib/x86_64-linux-gnu/libpthread.so.0
#1  0x0000562290a93de8 in cRwLock::Lock (this=this@entry=0x562290d66c90 <cRecordings::recordings+48>, Write=Write@entry=true, TimeoutMs=TimeoutMs@entry=0) at thread.c:176
#2  0x0000562290a94251 in cStateLock::Lock (this=this@entry=0x562290d66c80 <cRecordings::recordings+32>, StateKey=..., Write=Write@entry=true, TimeoutMs=TimeoutMs@entry=0) at thread.c:452
#3  0x0000562290a9e503 in cListBase::Lock (this=this@entry=0x562290d66c60 <cRecordings::recordings>, StateKey=..., Write=Write@entry=true, TimeoutMs=TimeoutMs@entry=0) at tools.c:2123
#4  0x0000562290a61004 in cRecordings::GetRecordingsWrite (TimeoutMs=0, StateKey=...) at recording.h:235
#5  cRecordingsLock::cRecordingsLock (Write=true, this=0x7f46686d7a50) at recording.h:291
#6  cResumeFile::Save (this=0x7f4654047ba0, Index=<optimized out>) at recording.c:318
#7  0x0000562290a0ce8a in cIndexFile::StoreResume (Index=<optimized out>, this=<optimized out>) at recording.h:474
#8  cDvbPlayer::Save (this=this@entry=0x7f4654051ea0) at dvbplayer.c:432
#9  0x0000562290a0ced4 in cDvbPlayer::~cDvbPlayer (this=0x7f4654051ea0, __in_chrg=<optimized out>) at dvbplayer.c:339
#10 0x0000562290a0db9d in cDvbPlayer::~cDvbPlayer (this=0x7f4654051ea0, __in_chrg=<optimized out>) at dvbplayer.c:346
#11 cDvbPlayerControl::Stop (this=this@entry=0x7f4654051490) at dvbplayer.c:1006
#12 0x0000562290a3a680 in cReplayControl::Stop (this=this@entry=0x7f4654051490) at menu.c:5506
#13 0x0000562290a3a90c in cReplayControl::~cReplayControl (this=0x7f4654051490, __in_chrg=<optimized out>) at menu.c:5466
#14 0x0000562290a3a999 in cReplayControl::~cReplayControl (this=0x7f4654051490, __in_chrg=<optimized out>) at menu.c:5469
#15 0x0000562290a59c53 in cControl::Shutdown () at player.c:105
#16 0x0000562290a8f46e in cSVDRPServer::CmdPLAY (this=0x7f4654000990, Option=<optimized out>) at svdrp.c:2061
#17 0x0000562290a91b44 in cSVDRPServer::Process (this=0x7f4654000990) at svdrp.c:2381
#18 0x0000562290a91d3e in cSVDRPServerHandler::ProcessConnections (this=this@entry=0x56229298cfc0) at svdrp.c:2488
#19 0x0000562290a91f88 in cSVDRPServerHandler::Action (this=0x56229298cfc0) at svdrp.c:2512
#20 0x0000562290a93fa9 in cThread::StartThread (Thread=0x56229298cfc0) at thread.c:288
#21 0x00007f46a047f424 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#22 0x00007f469ee269bf in clone () from /lib/x86_64-linux-gnu/libc.so.6

Alles anzeigen

Andreas

TomJoad · 3. April 2017

Das passiert, weil das svdrp-Kommando play sich einen Recordingslock holt und danach cControl::Shutdown aufruft. Dieses holt sich mutexlock von cControl. Dann soll die resume-Position weggeschrieben werden. Dazu will der dvbplayser index->StoreResume() aufrufen, welches sich einen Schreib-Lock auf Recordings holen will und da hängen bleibt.
Der vdr-main Task bleibt in Interact = Menu ? Menu : cControl::Control(); hängen, weil der den mutex von cControl nicht bekommt.
Vielleicht sollte dem gleichen Thread, der einen Read-Lock hält, gestattet werden, einen Schreib-Lock zu bekommen.

paulpanther · 3. April 2017

ich weiß nicht ob es damit zusammenhäng, soeben ist der VDR neu gestartet während ich die Aufnahme zeitversetzt geschaut habe. Der Neustart ist direkt nach dem beenden des Timers während dessen Wiedergabe geschehen.

Code

Apr  3 21:28:01 (MLD) user.info vdr: [3781] timer 2 (9 2012-2128 'Die Reimanns - Ein au..ergew..hnliches Leben') stop
Apr  3 21:28:04 (MLD) user.info vdr: [27366] VDR version 2.3.3 started

Grüße

kls · 4. April 2017

Der Deadlock sollte mit beliegendem Patch behoben sein.

Klaus

kls · 4. April 2017

paulpanther: das kann ich hier nicht nachvollziehen. Dürfte auch nichts mit dem SVDRP PLAY Problem zu tun haben.

Auf welchem Wert hast du denn "Delete timeshift recording" stehen?

Klaus

anbr · 4. April 2017

Hallo,

Zitat von kls

Der Deadlock sollte mit beliegendem Patch behoben sein.

ich danke dir für den Patch, der Deadlock ist damit nicht mehr reproduzierbar.

Grüße,
Andreas

[ANNOUNCE] VDR developer version 2.3.3

Jetzt mitmachen!

Teilen

Benutzer online in diesem Thema