[ANNOUNCE] VDR developer version 2.3.1

Zitat von maz

Die Funktion kenne ich noch aus dem enigma2-Lager, mich würde interessieren wie genau das gelöst ist. Kann man nun beim Drücken auf RECORD entscheiden, ob eine laufende Sendung, nach Dauer oder auch unbegrenzt aufgezeichnet wird?

Aus dem MANUAL:

Record key handling = 2
                         Defines what happens if the Record key on the remote control
                         is pressed during live tv.
                         0 = no instant recording
                         1 = confirm instant recording
                         2 = record instantly
                         The default is 2.

Es besteht also lediglich die Möglichkeit, die Taste ganz stillzulegen, eine Abfrage vorzuschalten, oder sie sofort wirken zu lassen. An der Aufnahmedauer usw. hat sich nichts geändert.

Zitat

...könnte man damit auch evtl. eine "undelete"-Funktion in VDR (nicht als Plugin) realisieren? Gelegentlich habe ich den Fall, dass ich kurz zuvor gelöschte Aufnahmen doch noch beibehalten möchte (ähnlich wie beim Papierkorb auf dem Desktop).

Da hat sich nichts grundlegendes geändert. Es gibt nach wie vor die DeletedRecordings-Liste. Lediglich das Handling der aus *dieser* Liste endgültig gelöschten Objekte wurde etwas verändert und benutzt jetzt den neuen, zentral für alle Listen verfügbaren "Garbage Collector".

Klaus

Vielen Dank erstmal für die neue Version!
Da sind aber einige Änderungen eingeflossen und viele Änderungen müssen bei den Plugins berücksichtigt werden
Ich denke aber das viele Änderungen gut und notwendig sind!

Für meine Skins und Plugins werde ich sicherlich ein wenig Zeit benötigen, werde ich aber (irgendwann) machen

Grüße
Martin

Die ganz ungeduldigen können sich schon mal das angepasste cec-plugin aus meinem git-repository laden (git clone http://git.uli-eckhardt.de/vdr-plugin-cecremote.git)

Interessant, da hat KLS ja was schönes entwickelt. Ich bin mal gespannt, ob sich das besser / einfacher bedienen lassen wird, als die bisherige Remotetimer Version.

Wenn ich das richtig sehe, dürfte ein Mischbetrieb aus alten VDR Versionen und der neuen Timer Handling ab 2.3.1 sich nicht in die Quere kommen und ein Mischbetrieb ist möglich?

VDR Versionen vor 2.3.1 nehmen einfach nicht am SVDRP-Peering teil, kriegen also davon gar nichts mit.

Ich kenne zwar das "remotetimers" Plugin nicht, aber ich schätze mal, recht viel einfacher und transparenter als im "Edit timer"-Menu den gewünschten VDR für die Aufnahme auszuwählen, geht es kaum ;-).

Würde mich aber natürlich schon sehr interessieren, wie diese neue Funktion ankommt und ob sie auch wirklich wie geplant funktioniert. Da gibt es nämlich zig verschiedene Fälle, die da zu berücksichtigen sind. Ich habe sie getestet, soweit ich sie mir vorstellen konnte, aber es kann natürlich sein, daß in der Praxis noch das eine oder andere Problem auftritt...

Klaus

Hier crasht VDR 2.3.1 + dvbsddevice mit Classic Skin reproduzierbar beim Löschen einer Aufzeichnung:

Program received signal SIGSEGV, Segmentation fault.
0x08136426 in cList<cRecording>::First (this=0x0) at tools.h:573
573       const T *First(void) const { return (T *)objects; }
(gdb) bt
#0  0x08136426 in cList<cRecording>::First (this=0x0) at tools.h:573
#1  0x0815afa9 in cRecordings::MBperMinute (this=0x0) at recording.c:1573
#2  0x081b90b0 in cVideoDiskUsage::HasChanged (State=@0x828f9f4: 2)
    at videodir.c:214
#3  0x081b919a in cVideoDiskUsage::String () at videodir.c:231
#4  0x0816f3ec in cSkinClassicDisplayMenu::DrawTitle (this=0xafad8158)
    at skinclassic.c:282
#5  0x0816f535 in cSkinClassicDisplayMenu::SetTitle (this=0xafad8158,
    Title=0xb33fad40 "Abenteuer Leben - täglich neu entdecken")
    at skinclassic.c:288
#6  0x08140770 in cOsdMenu::Display (this=0xafae4a90) at osdbase.c:238
#7  0x081251d6 in cMenuRecordings::Delete (this=0xafae4a90) at menu.c:3119
#8  0x0812580f in cMenuRecordings::ProcessKey (this=0xafae4a90, Key=kYellow)
    at menu.c:3186
#9  0x0814188f in cOsdMenu::ProcessKey (this=0xafacf1b0, Key=kYellow)
    at osdbase.c:528
#10 0x08125775 in cMenuRecordings::ProcessKey (this=0xafacf1b0, Key=kYellow)
    at menu.c:3177
#11 0x0814188f in cOsdMenu::ProcessKey (this=0xafadc8b0, Key=kYellow)
    at osdbase.c:528
#12 0x0812e364 in cMenuMain::ProcessKey (this=0xafadc8b0, Key=kYellow)
    at menu.c:4372
#13 0x081b6842 in main (argc=6, argv=0xbffff7d4) at vdr.c:1354
(gdb)

CU
Oliver

Zitat von kls

Ich kenne zwar das "remotetimers" Plugin nicht, aber ich schätze mal, recht viel einfacher und transparenter als im "Edit timer"-Menu den gewünschten VDR für die Aufnahme auszuwählen, geht es kaum ;-).

Ich hätte schon gedacht das Du es Dir mal ansiehst, da stecken auch ein paar gute Ideen drinnen. Meine Frau merkt sein Jahren nicht das sie das Plugin nutzt. Ich hätte auch da gesagt das es nicht einfacher geht.
Aber wenn man bei dem neuen Mechanismus eine default location definieren kann, dann ist es ein voller Ersatz.

Frage dazu, welche EPG Daten werden dann in die Info Datei gespeichert? Die vom Client oder die vom Server?
Können ja durchaus unterschiedliche sein. Mein Server hat EPG Daten aus unterschiedlichen Quellen und die Clients nur die aus dem Stream.

Zitat von UFO

Hier crasht VDR 2.3.1 + dvbsddevice mit Classic Skin reproduzierbar beim Löschen einer Aufzeichnung:

Anbei der Fix.

Klaus

Zitat von kls

Würde mich aber natürlich schon sehr interessieren, wie diese neue Funktion ankommt und ob sie auch wirklich wie geplant funktioniert. Da gibt es nämlich zig verschiedene Fälle, die da zu berücksichtigen sind. Ich habe sie getestet, soweit ich sie mir vorstellen konnte, aber es kann natürlich sein, daß in der Praxis noch das eine oder andere Problem auftritt..

sobald ich das Ding auf Server und Client am Start hab werde ich es ausgiebig testen, danke für die tolle Erweiterung.

louis: ich würde es nicht davon abhängig machen welche VDR Version verwendet wird sondern davon ob remotetimers geladen ist oder nciht: kann ja sein das ich auf den Clients 2.3.1 mit remotetimers einsetzen will weil sein Server noch auf 2.2.0 arbeitet. Andersrum geht natürlich nicht

Christian

Zitat von fnu

Nur für mich zum Verständnis, beinhaltet die Peer-to-Peer Funktion auch die Aufnahmen?

Noch nicht, aber mit dem jetzt vorhandenen "Peering-Fundament" werde ich da wohl noch einiges machen... ;-).

Klaus

Zitat von decembersoul

Aber wenn man bei dem neuen Mechanismus eine default location definieren kann, dann ist es ein voller Ersatz.

Kann man:

Setup/Miscellaneous:


  SVDRP peering = no     Activates automatic connections between VDRs in the same
                         network.


  SVDRP host name        The name of this VDR, which is used when connecting VDRs
                         via SVDRP. By default, the machine's host name is used.


  SVDRP default host     The name of the VDR to be used by default when creating a
                         new timer.

Zitat von decembersoul

Frage dazu, welche EPG Daten werden dann in die Info Datei gespeichert? Die vom Client oder die vom Server?

Immer die von der Maschine, auf der der Timer ausgeführt wird.

Klaus

OT hier aber ich hab noch nicht den Sinn mit den Aufnahmen verstanden. Mit dem avahi Linker hol ich mir ja eh Aufnahmen/Musik/Bilder der teilnehmenden "VDR Computer" in den Mount, warum soll dann der VDR das mit den medien Managen.

Timer ist ja was anderes weil das ja ein Objekt ist was explizit nur für den VDR gedacht ist.

Christian

Danke für die Aufstellung Klaus:

ich hab jetzt ein Lan von verschiedenen VDR, möchte das genau einer der VDR nicht mitspielt: wie kann ich den quasi blacklisten? Oder andersherum: wie kann ich alles blacklisten ausser einer whitelist auf den Sever, also nicht mehr peer to peer sondern jeweils client mit server?

Christian

Das geht im Moment noch nicht.
Wie wäre es mit einer Setup-Option, über die man einstellen kann, daß Peering ausschließlich mit dem Default-Server gemacht werden soll? Damit müsstest du doch genau das erreichen können, oder?

Klaus

genau, die Clients sind reine Konsumenten und haben nur ne kleine SSD und nur einen Tuner zum schauen, könnten eh nix machen ausser zwei Stunden Timeshifen - folglich gibts auf den Clients prinzipiell keine Timer/Aufnahmen die von Interesse wären.

Dem anderen VDR von meinem Dad, der der nicht mitspielen soll, gebe ich dann "SVDRP peering = no" und er ist ganz raus, richtig?

Christian

Auch auf die Gefahr hin, dass das nur ich so sehe, aber wo ist denn überhaupt der Vorteil von "Peer to peer"?

Wenn ich "Standalone-Systeme" (mit Tuner und Platte) habe, dann brauche ich keine Timerübertragung. Zumal diese Receiver ja eher nicht durchlaufen sondern selber aufwachen. Sie sind also nicht permanent im Netz erreichbar.

Wenn es einen zentralen Server gibt, dann ist es auch kein großer Aufwand dessen IP in der Einstellung des Client-VDR einzutragen.

Zitat von CKone

Dem anderen VDR von meinem Dad, der der nicht mitspielen soll, gebe ich dann "SVDRP peering = no" und er ist ganz raus, richtig?

Richtig.

Klaus

Zitat von kls

Anbei der Fix.

Danke. Hier gleich der nächste Crash. Löschen einer Aufzeichnung, während sie wiedergegeben wird:

Program terminated with signal 11, Segmentation fault.
#0  0x08136426 in cList<cRecording>::First (this=0x0) at tools.h:573
573       const T *First(void) const { return (T *)objects; }
(gdb) bt
#0  0x08136426 in cList<cRecording>::First (this=0x0) at tools.h:573
#1  0x081364f1 in cList<cRecording>::First (this=0x0) at tools.h:585
#2  0x0815b2d0 in cRecordings::ResetResume (this=0x0,
    ResumeFileName=0x91291e8 "/video/Abenteuer_Leben_-_täglich_neu_entdecken/%%Thema_u._a.:_Wilde_Kost:_Essbares_Unkraut,_Information,_D_2015/2015-09-15.16.56.29-0.rec/resume") at recording.c:1632
#3  0x081561c8 in cResumeFile::Save (this=0x912b0dc, Index=0)
    at recording.c:319
#4  0x080f7ae9 in cIndexFile::StoreResume (this=0x912b0c0, Index=0)
    at recording.h:476
#5  0x080f528c in cDvbPlayer::Save (this=0xe552c98) at dvbplayer.c:398
#6  0x080f4b65 in cDvbPlayer::~cDvbPlayer (this=0xe552c98,
    __in_chrg=<optimized out>) at dvbplayer.c:305
#7  0x080f4c93 in cDvbPlayer::~cDvbPlayer (this=0xe552c98,
    __in_chrg=<optimized out>) at dvbplayer.c:312
#8  0x080f7718 in cDvbPlayerControl::Stop (this=0x912ec98) at dvbplayer.c:962
#9  0x081334b5 in cReplayControl::Stop (this=0x912ec98) at menu.c:5496
#10 0x0813311f in cReplayControl::~cReplayControl (this=0x912ec98,
    __in_chrg=<optimized out>) at menu.c:5456
#11 0x081331b7 in cReplayControl::~cReplayControl (this=0x912ec98,
    __in_chrg=<optimized out>) at menu.c:5459
#12 0x081512db in cControl::Shutdown () at player.c:105
#13 0x08125142 in cMenuRecordings::Delete (this=0xe5d8e10) at menu.c:3112
#14 0x0812580f in cMenuRecordings::ProcessKey (this=0xe5d8e10, Key=kYellow)
    at menu.c:3186
#15 0x0814188f in cOsdMenu::ProcessKey (this=0x9127770, Key=kYellow)
    at osdbase.c:528
#16 0x08125775 in cMenuRecordings::ProcessKey (this=0x9127770, Key=kYellow)
    at menu.c:3177
#17 0x0814188f in cOsdMenu::ProcessKey (this=0xe552830, Key=kYellow)
    at osdbase.c:528
#18 0x0812e364 in cMenuMain::ProcessKey (this=0xe552830, Key=kYellow)
    at menu.c:4372
#19 0x081b6842 in main (argc=18, argv=0xbfb595a4) at vdr.c:1354
(gdb)

CU
Oliver