[ANNOUNCE] VDR developer version 2.3.7

MegaX · June 11, 2017 at 4:38 PM

Code

VDR developer version 2.3.7 is now available at


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


A 'diff' against the previous version is available at


      ftp://ftp.tvdr.de/vdr/Developer/vdr-2.3.6-2.3.7.diff


MD5 checksums:


0df2c8b40c89d142c698200ac3dcb14a  vdr-2.3.7.tar.bz2
fbe211e46b12a2fcf2f19054d3ce62cf  vdr-2.3.6-2.3.7.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.6:


- Fixed false positives when checking the locking sequence, in case of nested locks
  within the same thread.
- Fixed uninitialized variable SdWatchdog in vdr.c (reported by Frank Neumann).
- Fixed the locking sequence when starting an instant recording.
- Fixed L(ock) and U(nlock) indicators in cStateLockLog.
- Increased SLL_LENGTH in thread.c to better handle long caller lines, and enclosed
  logCaller with DEBUG_LOCKCALL to preserve memory in normal operation.
- Fixed a typo in CAMMENURETYTIMEOUT and added logging CAM enquiries.
- The new configuration file 'camresponses.conf' can be used to define automatic
  responses to CAM menus, for instance to avoid annyoing popup messages or entering
  the parental rating PIN. See vdr.5 for details.
- The option "Setup/Miscellaneous/Show channel names with source" can now be set to
  "type" or "full" to show either the type or the full name of the source (thanks to
  Martin Wache).
- The "Channels" menu now indicates whether a channel is encrypted ('X') or a radio
  channel ('R') (thanks to Martin Wache).
- Changed ##Lock to ##_Lock in the DEF_LIST_LOCK and USE_LIST_LOCK macros defined
  in tools.h, so that there is no cSchedulesLock any more. The epgsearch plugin still
  had an abandoned member of class cSchedulesLock, which, as a side effect, caused an
  invalid lock sequence to be flagged (reported by Johann Friedrichs). In order to
  have the compiler report such things, these macros have been changed.
- Introduced the new macro DISABLE_TEMPLATES_COLLIDING_WITH_STL, which can be defined
  before including tools.h in case some plugin needs to use the STL and gets error
  messages regarding one of the template functions defined in tools.h.


Have fun!


Klaus

Display More

MegaX · June 11, 2017 at 4:40 PM

Hi Klaus,

auch diesmal wieder vielen Dank für die neue Version.

jsffm · June 11, 2017 at 5:29 PM

Erst mal vielen Dank an Klaus für die neue Version

Leider auch ein Problem mit streamdev:

Code

connectionVTP.c:44:2: error: ‘cSchedulesLock’ does not name a type
  cSchedulesLock    *m_SchedulesLock;
  ^
connectionVTP.c: In destructor ‘cLSTEHandler::~cLSTEHandler()’:
connectionVTP.c:213:9: error: ‘m_SchedulesLock’ was not declared in this scope
  delete m_SchedulesLock;
         ^

kls · June 11, 2017 at 5:36 PM

Ich vermute mal, daß m_SchedulesLock nirgendwo wirklich verwendet wird. Daher einfach mal komplett löschen.

Und bei der Gelegenheit auch gleich noch schauen, ob es irgendwo ein Member vom Typ (cSchedules *) gibt, über das sich das Plugin einen längerfristigen Pointer auf die Schedules merkt. Das ist seit dem strikten Locking nicht mehr zulässig. Man muß sich den Pointer immer neu holen, wenn man ihn braucht.

Klaus

fnu · June 11, 2017 at 6:32 PM

Bei so schönen Wetter sitzt man auf dem Motorrad und veröffentlicht keine neue VDR Version ...

Vielen Dank für Deine Mühen und die neue Version.

Gruß
FRank

jasminj · June 11, 2017 at 10:39 PM

Quote from jsffm

Leider auch ein Problem mit streamdev

GuckstDU hier.

hopsi · June 12, 2017 at 6:27 PM

EDIT: Der Crash tritt nur auf, wenn ich osd2web aktiviert habe. Ich poste das daher im entsprechenden Thread nochmal.
EDIT2: Für's Protokoll: war ein osd2web-Problem und ist dort gefixt.

Habe hier einen Segfault beim Tunen auf Sparhandy TV.

Code

Sparhandy TV;BetaDigital:12460:HC34M2S0:S19.2E:27500:3071=2:3072=deu@3:0:0:659:133:5:0

Code

(gdb) bt
#0  cEvent::ChannelID (this=this@entry=0x0) at epg.c:153
#1  0x00007f101f0ead03 in Matches (ti=ti@entry=0xeb3350, event=event@entry=0x0) at tools.c:27
#2  0x00007f101f0eaefb in getTimerMatch (timers=timers@entry=0x8130c0 <cTimers::timers>,
    event=event@entry=0x0, match=match@entry=0x7f0fc77fddec) at tools.c:71
#3  0x00007f101f0ea368 in cUpdate::updatePresentFollowing (this=this@entry=0xf9a510) at status.c:185
#4  0x00007f101f0e3cc8 in cUpdate::atMeanwhile (this=this@entry=0xf9a510) at update.c:218
#5  0x00007f101f0e44d9 in cUpdate::Action (this=0xf9a510) at update.c:289
#6  0x000000000052dc59 in cThread::StartThread (Thread=0xf9a528) at thread.c:293
#7  0x00007f102414f46d in start_thread () from /lib64/libpthread.so.0
#8  0x00007f1022a8483d in clone () from /lib64/libc.so.6
(gdb) quit

Display More

Mit 2.3.6 tritt das nicht auf, wobei ich auch die Plugins teilweise zwischen 2.3.6 und 2.3.7 geupdated habe.

Christian

Ulrich Eckhardt · June 15, 2017 at 7:16 PM

Ich hätte da mal einen Wunsch für eine Erweiterung des VDR. Aktuell unterstützt der VDR ja nur ein aktives OSD-Menü. Für graphtft musste man deswegen den VDR immer patchen. Jetzt wäre es schön, wenn man z.B. auch für das neue osd2web Plugin im Zuge der Weiterentwicklung vielleicht auch mal die API aufbohren könnte. Es gibt doch einige Personen, die dem alten Verhalten von graphtft nachtrauern

clausmuus · June 16, 2017 at 12:43 PM

Hi,

wenn man das noch ein wenig flexibler gestalten möchte, wünsche ich mir schon sein langem die Möglichkeit mehrere OSDs haben zu können. Es wäre also schön wenn solche Plugins wie das graphtft, osd2web oder restfulapi ein OSD öffnen können, dass auf dem Haupt Ausgabedevice nicht angezeigt wird. Das OSD des Ausgabedevices sollte von den Plugins nicht gestört werden.

Claus

mini73 · June 16, 2017 at 12:45 PM

Wenn ich das richtig in Erinnerung habe, dann hat horchi mit Klaus schon darüber diskutiert.

Lars.

CKone · June 16, 2017 at 12:48 PM

Quote from clausmuus

Es wäre also schön wenn solche Plugins wie das graphtft, osd2web oder restfulapi ein OSD öffnen können, dass auf dem Haupt Ausgabedevice nicht angezeigt wird.

Genau das geht aber doch, zumindest mit osd2web.

Quote from clausmuus

Das OSD des Ausgabedevices sollte von den Plugins nicht gestört werden.

Und genau das geht eben nicht, zu einer Zeit nur ein OSD, aber warum willst du den VDR von zwei Stellen konkurrierend bedienen?

Christian

Frodo · June 16, 2017 at 1:43 PM

Weshalb gibt es dann einen osd2web Patch für den VDR?

CKone · June 16, 2017 at 1:50 PM

Weil das wie immer schlecht dokumentiert ist, es wird gefühlt seit 2.3.4 oder 5 kein Patch mehr im vdr benötigt. Jörg sollte den dringend aus dem Source nehmen wenn noch nicht geschehen

clausmuus · June 17, 2017 at 1:47 PM

Quote from CKone

Und genau das geht eben nicht, zu einer Zeit nur ein OSD, aber warum willst du den VDR von zwei Stellen konkurrierend bedienen?

Je nach Plugin hat das verschiedene Gründe:
- restfulapi: Das setze ich im Webinterfave ein, um einen VDR über den Browser zu konfigurieren. Und das würde ich gerne machen, ohne auf dem Hauptausgabe Device ein OSD zu öffnen, also z.B. während meine Frau TV schaut.
- osd2web: Genau wie restfulapi
- graphtft: um z.B. Timer programmieren zu können, ohne das das OSD auf dem TV auf geht.
- xineliboutput: Um mehrere vollwertige Clients mit nur einem VDR nutzen zu können
- MPV-VDR-Streamdev-Client: Um beliebig viele Clients (auf beliebigen Plattformen) mit vollwertigem VDR OSD nutzen zu können
- ...

Claus

kls · June 17, 2017 at 2:05 PM

Also mehrere OSDs gleichzeitig, die unabhängig voneinander bedient werden können, das geht schon mal überhaupt nicht! Das Chaos, das dadurch enstehen kann, möchte ich mir nicht antun.

Zu einer Zeit genau *ein* OSD ist sicherlich die einfachste und sauberste Lösung.

Sollte es gleichzeitig mehrere OSDs geben, so müssten diese vollkommen synchron laufen. Das heißt, jede über die FB ausgelöste Aktion müsste gleichzeitig auf allen OSDs dargestellt werden. Das scheitert aber allein schon daran, daß jedes OSD eine andere Zahl von Menüzeilen haben kann. Der Aufwand, hierfür eine einfache Lösung zu finden, erscheint mir unverhältnismäßig hoch.

Klaus

3PO · June 17, 2017 at 4:14 PM

Nun, dass nur Einer eine Eingabe zur selben Zeit machen kann, sehe ich ein und das macht ja auch Sinn, aber weshalb sollt denn die Ausgabe nicht auf mehreren "Geräten" gleichzeitig erfolgen können?

Man könnte doch sicherlich dafür sorgen, dass wenn von "Gerät 1" ein Eingabe Event kommt, dann die Eingabe für x Millisekunden die Eingabe für alle Andern gesperrt ist, oder?

kls · June 18, 2017 at 11:13 AM

Das Hauptproblem sind die unterschiedlichen Zeilenzahlen der Menüs. Wenn sichergestellt werden könnte, daß alle OSDs immer die selbe Zahl an Menüzeilen haben, dann wäre es vielleicht denkbar.

Klaus

3PO · June 18, 2017 at 11:35 AM

Wer legt denn die Anzahl der anzuzeigenden Zeilen der entsprechenden Menüs fest, der VDR, oder die Plugins?

kls · June 18, 2017 at 11:40 AM

Das legt jede Skin für sich individuell fest:

Code

class cSkinDisplayMenu : public cSkinDisplay {
  ...
  virtual int MaxItems(void) = 0;
       ///< Returns the maximum number of items the menu can display.

Hängt z.B. ab von der Größe des OSDs und des verwendeten Fonts.

Klaus

Ulrich Eckhardt · June 19, 2017 at 9:33 PM

Quote from kls

Das heißt, jede über die FB ausgelöste Aktion müsste gleichzeitig auf allen OSDs dargestellt werden.

Ja, ansonsten wird das auch für den Bediener schnell unübersichtlich

Quote

Das scheitert aber allein schon daran, daß jedes OSD eine andere Zahl von Menüzeilen haben kann.

Das Problem ist doch im Prinzip einfach lösbar. Jedes Skin/OSD kümmert sich selber um das Zeichnen der Menüs incl Scrolling. Der VDR braucht dann nur Hoch/Runter und ggf noch Anfang/Ende des Menüs zu liefern. So ist doch sichergestellt, dass immer eindeutig eine Menüzeile ausgewählt ist. Allenfalls für ein Page-Up/Down müsste man halt die kleinste darstellbare Zeilenzahl der aktiven OSDs als Offset für alle OSDs verwenden.

[ANNOUNCE] VDR developer version 2.3.7

Participate now!

Users Viewing This Thread