[ANNOUNCE] VDR developer version 1.7.33

Dirk · 8. Dezember 2012

Zitat

VDR developer version 1.7.33 is now available at

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

A 'diff' against the previous version is available at

ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.32-1.7.33.diff

MD5 checksums:

7c21451360ac7959d0d95e533d34451c vdr-1.7.33.tar.bz2
c79257198f8569bc02f43dc470ee3076 vdr-1.7.32-1.7.33.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.

IMPORTANT:
==========

This version of VDR no longer sets LC_NUMERIC to "C" in order to make
sure any floating point numbers written to configuration files use a
proper decimal point. It rather explicitly converts such numbers using the
new functions atod() and dtoa().
IF YOU USE PLUGINS THAT STORE FLOATING POINT NUMBERS IN THEIR OWN CONFIGURATION
FILES, YOU SHOULD SET
export LC_NUMERIC=C
BEFORE RUNNING VDR, UNTIL THESE PLUGINS HAVE BEEN PROPERLY UPDATED.

The changes since version 1.7.32:

- In order to be able to play TS recordings from other sources, in which there is
more than one PMT PID in the PAT, 'int cPatPmtParser::PatPmt(void)' has been changed
to 'bool cPatPmtParser::IsPatPmt(int Pid)'.
- Fixed learning remote control keys with the LCARS skin.
- Updated the Macedonian OSD texts (thanks to Dimitar Petrovski).
- Fixed getting only non-video packets in cCuttingThread::GetPendingPackets() (reported
by Sören Moch).
- Changed all occurrences of MPEG4 to H264 (pointed out by Sören Moch).
- Fixed getting the number of editing sequences in case the last sequence has no actual
end mark.
- The cutter now only increments the TS continuity counter for packets that have a
payload (pointed out by Sören Moch).
- Fixed adjusting the DTS values in the cutter, to compensate for dropped B-frames
(pointed out by Sören Moch).
- Fixed a typo in skins.h (thanks to Lars Hanisch).
- Simplified calculating the PTS offset in cPtsFixer::Fix() and fixed the overflow
handling of PCR values (thanks to Sören Moch).
- Fixed calling iconv_close() only with a valid iconv_t value (thanks to Juergen Lock).
- Fixed faulty opening of the Recordings menu when pressing the Play key during normal
live viewing mode in case there is a "last viewed" recording.
- Fixed some #include statements in plugins to use <vdr/...> instead of "vdr/..."
(thanks to Lars Hanisch).
- Fixed some spellings in osd.h and svdrp.c (thanks to Ville Skyttä).
- Fixed handling lowercase polarization characters in channel definitions if no DiSEqC
is used (reported by Mike Hay, actual bug pointed out by Stefan Huelswitt).
- Synchronizing system time to the transponder time is now done using adjtime() in order
to avoid discontinuities (suggested by Manuel Reimer). If the time difference is more
than 10 seconds, stime() is still used to do the initial sync.
- The '7' and '9' keys now jump to the very beginning or end, respectively, of the
recording, even if there is no mark set at that point (following a request from
Andre Weidemann).
- Now always setting the TDT EIT filter, because otherwise when turning on using the
transponder time in the Setup menu, it would only be used after the next restart
of VDR (thanks to Sundararaj Reel).
- The new functions cDevice::CanScaleVideo() and cDevice::ScaleVideo() can be used by
derived output devices to implement scaling the video to a given size and location
(based on a suggestion by Lucian Muresan).
- The SVDRP command HITK now discards any keys if the remote control is currently
turned off (thanks to Alexander Hans).
- The new remote control key "Play/Pause" can be used with remote controls that don't
have separate keys for "Play" and "Pause", but rather have a single key for both
functions (thanks to Stefan Hofmann for suggesting to implement support for such
remote controls).
- The new option "Setup/Replay/Pause on mark set" can be used to activate automatically
going into Pause mode if an editing mark is set during replay (suggested by Andre
Weidemann).
- When regenerating the index of a recording, the frame rate stored in the info file
is now automatically fixed if it differs from the value detected by the frame
detector.
- Fixed creating the edited version directory if a relative file name is given in
the call to 'vdr --edit' (the '/video' part was stripped from the given file name
even if it wasn't there).
- The new option "Setup/Replay/Progress display time" can be used to activate
automatically displaying the progress display whenever replay of a recording is
started (suggested by Stefan Blochberger).
- Changed reading and writing of floating point numbers into configuration files to
make it independent of the decimal point used in the current locale. All calls to
atof() have been replaced with the new function atod(), which makes sure the string
representation of a floating point number using a '.' as decimal point will be
handled correctly, even if the locale in use expects a ',' as the decimal point.
Plugins that read floating point numbers from their own configuration files will
also need to use atod() for this, or use a method of their own (this is not necessary
if values are stored in VDR's setup.conf file, because VDR takes care of this).
The reason for these changes is that floating point numbers presented to the user
shall be displayed in the way defined by the current locale (suggested by Stefan
Blochberger).
If you use plugins that store floating point values in configuration files of their
own and have not yet been adapted to this change, you should set
export LC_NUMERIC=C
before running VDR. Otherwise your plugin's configuration data may not be read or
written correctly.
- The new functions SetItemEvent(), SetItemTimer(), SetItemChannel() and
SetItemRecording() of the cSkinDisplayMenu class can be reimplemented by skin
plugins to display these items in a more elaborate way than just a simple line of
text.

Have fun!

Klaus

Alles anzeigen

FireFly · 8. Dezember 2012

Wow! Danke Klaus, da sind mit LC_NUMERIC und SetItem* ja gleich zwei Wünsche in Erfüllung gegangen ... sogar vor Weihnachten

Wenn man die vier neuen Methoden SetItem* im Skin implementiert, muss man dann noch SetItem() implementieren? Evtl. für Plugins?

Außerdem würde mich interessieren, ob der Cutting-Algorithmus jetzt als stabil anzusehen ist oder ob die Gefahr besteht, sich damit Aufnahmen zu beschädigen.

Grüße
FireFly

CKone · 8. Dezember 2012

Prima, danke für die neue Version:

Code

- The '7' and '9' keys now jump to the very beginning or end, respectively, of the
recording, even if there is no mark set at that point (following a request from
Andre Weidemann).

ok, mag sein das ich auf dem Schlauch stehe aber mit welchen Tasten würde man dann sinnvollerweise zwischen den Marken springen, wenn 7/9 jetzt anderweitig belegt sind?

Christian

fnu · 8. Dezember 2012

Zitat von CKone

ok, mag sein das ich auf dem Schlauch stehe aber mit welchen Tasten würde man dann sinnvollerweise zwischen den Marken springen, wenn 7/9 jetzt anderweitig belegt sind?

Ja, das würde mich in der Tat auch interessieren? Wie auch die Frage warum man eine gute funktionierende Lösung dann einfach über Board schmeißt?

Ich hege ja schon wieder den Verdacht, dass sich mal wieder ein einzelner echauffiert hat, während die schweigende Mehrheit zufrieden mit der alten sehr guten und geprüften Umsetzung war ...

Aber ich hoffe das bezieht sich nur auf das Verhalten von "7" und "9" wenn keine Schnittmarken da sind bzw. das "7" von der ersten Eingangsmarke zum Anfang der Aufnahme springt und "9" von der letzten Ausgangsmarke zum Aufnahmeende? Was seither nicht der Fall ist ...

Regards
fnu

CKone · 8. Dezember 2012

Zitat von fnu

Wie auch die Frage warum man eine gute funktionierende Lösung dann einfach über Board schmeißt?

Bin mir grad nicht sicher ob das bisher aus nem Patch kam, möglicherweise waren die Tasten aus Klaus' Sicht noch frei?

Christian

FireFly · 8. Dezember 2012

Zitat von CKone

ok, mag sein das ich auf dem Schlauch stehe aber mit welchen Tasten würde man dann sinnvollerweise zwischen den Marken springen, wenn 7/9 jetzt anderweitig belegt sind?

Probier's doch mal aus Ich habe noch'n paar Plugins die noch nicht kompilieren....
Aber die Frage hatte ich mir auch gestellt; ich vermute mal, dass jetzt am Anfang und Ende sozusagen "virtuelle" Schnittmarken sind, d.h. wenn man auf der ersten Marke steht springt man mit 7 an den Anfang und auf der letzten Marke springt man mit 9 ans Ende.

kls · 8. Dezember 2012

Zitat von CKone
Prima, danke für die neue Version:
Code
- The '7' and '9' keys now jump to the very beginning or end, respectively, of the
recording, even if there is no mark set at that point (following a request from
Andre Weidemann).
ok, mag sein das ich auf dem Schlauch stehe aber mit welchen Tasten würde man dann sinnvollerweise zwischen den Marken springen, wenn 7/9 jetzt anderweitig belegt sind?

Die sind nicht "anderweitig belegt"! Sie springen halt jetzt nur auch zum Anfang bzw. Ende, wenn man auf der ersten bzw. letzten Marke steht, oder gar keine Marken definiert sind.
Ansonsten ist das Verhalten unverändert.

Klaus

jsffm · 8. Dezember 2012

gelöscht, Problem lag wohl bei mir

CKone · 8. Dezember 2012

Zitat von kls

Die sind nicht "anderweitig belegt"! Sie springen halt jetzt nur auch zum Anfang bzw. Ende, wenn man auf der ersten bzw. letzten Marke steht, oder gar keine Marken definiert sind.
Ansonsten ist das Verhalten unverändert.

danke für die Erklärung, dann ist ja "alles gut", sogar besser als vorher! - hatte es jedoch so interpretiert, dass nur noch von ganz vorn nach ganz hinten gesprungen werden kann

Christian

kls · 8. Dezember 2012

Zitat von FireFly

Wenn man die vier neuen Methoden SetItem* im Skin implementiert, muss man dann noch SetItem() implementieren? Evtl. für Plugins?

Ja, SetItem() muß auf jeden Fall implementiert werden, da sonst "normale" Menüs nicht angezeigt werden würden.
Außerdem steht ja im Kommentar:

Code

///< The default implementation does nothing and returns false, which results in
       ///< a call to SetItem() with a proper text.

Zitat

Außerdem würde mich interessieren, ob der Cutting-Algorithmus jetzt als stabil anzusehen ist oder ob die Gefahr besteht, sich damit Aufnahmen zu beschädigen.

Es gibt noch kleine Probleme, aber im Großen und Ganzen geht es schon recht gut.

Klaus

lostinspc · 8. Dezember 2012

kls: Danke für das nachträgliche Nikolausgeschenk

@all: Bei mir kompiliert epgsearch nicht mehr. Meinem bescheidenen Verständnis nach zu urteilen hat sich der Methodenaufruf von cTimers::GetMatch geändert?

Code

g++ -g -O3 -Wall -Werror=overloaded-virtual -Wno-parentheses -fPIC -c -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_GNU_SOURCE -DSENDMAIL='"/usr/sbin/sendmail"' -DHAVE_PCREPOSIX -DPLUGIN_NAME_I18N='"epgsearch"' -I../../../include -I/include epgsearchtools.c
epgsearchsvdrp.c: In member function ‘virtual cString cPluginEpgsearch::SVDRPCommand(const char*, const char*, int&)’:
epgsearchsvdrp.c:565:52: error: no matching function for call to ‘cTimers::GetMatch(const cEvent*&, int*)’
../../../include/vdr/timers.h:118:11: note: candidates are: cTimer* cTimers::GetMatch(time_t)
../../../include/vdr/timers.h:119:11: note:                 cTimer* cTimers::GetMatch(const cEvent*, eTimerMatch*)
make[1]: *** [epgsearchsvdrp.o] Error 1

Grüße, Peter

Copperhead · 8. Dezember 2012

Hier sind ein paar Patches, damit die Plugins wieder laufen.

jsffm · 8. Dezember 2012

zaphistory-0.9.5 compiliert bei mir nicht:

Code

epg_item.c: In Elementfunktion »bool cMenuMyScheduleItem::Update(bool)«:
epg_item.c:41:50: Fehler: keine passende Funktion für Aufruf von »cTimers::GetMatch(const cEvent*&, int*)«
../../../include/vdr/timers.h:118:11: Anmerkung: Kandidaten sind: cTimer* cTimers::GetMatch(time_t)
../../../include/vdr/timers.h:119:11: Anmerkung:                  cTimer* cTimers::GetMatch(const cEvent*, eTimerMatch*)
epg_item.c:82:19: Warnung: ignoring return value of »int asprintf(char**, const char*, ...)«, declared with attribute warn_unused_result
make[1]: *** [epg_item.o] Fehler 1

lostinspc · 8. Dezember 2012

Zitat von Copperhead

Hier sind ein paar Patches, damit die Plugins wieder laufen.

Dankeschön!

mase · 8. Dezember 2012

Danke für die neue Version!

burn kompiliert auch nicht:

Code

scanner.c: In member function ‘vdr_burn::track_info_list& vdr_burn::pes_scanner::ts_scan(cPatPmtParser&, const position&, const position&, bool)’:
scanner.c:408:35: error: ‘class cPatPmtParser’ has no member named ‘PmtPid’
scanner.c:413:111: error: ‘class cPatPmtParser’ has no member named ‘PmtPid’
make[1]: *** [scanner.o] Fehler 1

FireFly · 8. Dezember 2012

Jetzt bin ich auch in den dvbhddevice/libhdffcmd-Make-Fehler reingelaufen:

Code

/usr/lib64/gcc/x86_64-suse-linux/4.6/../../../../x86_64-suse-linux/bin/ld: bitbuffer.o: relocation R_X86_64_PC32 against undefined symbol `memset@@GLIBC_2.2.5' can not be used when making a shared object; recompile with -fPIC
/usr/lib64/gcc/x86_64-suse-linux/4.6/../../../../x86_64-suse-linux/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status

Ursache ist, dass die Variable PLUGIN von dvbhddevice/Makefile nicht an das Unterverzeichnis dvbhddevice/libhdffcmd/Makefile weiter geben wird und damit die Definitionen in Make.config / Make.global nicht greifen. Abhilfe schafft lt. http://www.gnu.org/software/ma…l#Variables_002fRecursion ein

Diff

--- Makefile.org        2012-12-08 18:30:01.250135758 +0100
+++ Makefile    2012-12-08 18:27:47.922882959 +0100
@@ -9,7 +9,7 @@
 # IMPORTANT: the presence of this macro is important for the Make.config
 # file. So it must be defined, even if it is not used here!
 #
-PLUGIN = dvbhddevice
+export PLUGIN = dvbhddevice
 
 ### The version number of this plugin (taken from the main source file):

und damit funktionierts bei mir wieder. Ja, auch in Makefiles kann man Variablen exportieren

mase: Du musst bei burn in scanner.c die Zeile 407 ersetzen:

Code

#if VDRVERSNUM < 10733
                    else if (Pid == PatPmtParser.PmtPid())
#else
                    else if (PatPmtParser.IsPmtPid(Pid))
#endif

und das logger::debug fünf Zeilen später auskommentieren oder durch folgendes ersetzen:

Code

logger::debug(format( "PID found: Vpid=0x{1}, Vtype=0x{2}") % format::base( PatPmtParser.Vpid(), 16 ) % format::base( PatPmtParser.Vtype(), 16 ));

rudirabbit · 8. Dezember 2012

Hi,

Zitat von FireFly

Jetzt bin ich auch in den dvbhddevice/libhdffcmd-Make-Fehler reingelaufen:

Sowas ähnliches hatten wir schon .
Ist wohl noch nicht eingeflossen ?

FireFly · 8. Dezember 2012

Zitat von rudirabbit

Sowas ähnliches hatten wir schon .

Ja ich weiß, aber irgendwie bin ich jetzt zu ner ganz anderen Lösung gekommen - die mir ehrlich gesagt wesentlich plausibler und einfacher erscheint ...

rudirabbit · 8. Dezember 2012

Zitat von FireFly

Ja ich weiß, aber irgendwie bin ich jetzt zu ner ganz anderen Lösung gekommen - die mir ehrlich gesagt wesentlich plausibler und einfacher erscheint ...

Wie schau die alternative Lösung aus ?

Ok,

Zitat

Ja, auch in Makefiles kann man Variablen exportieren

denke nun habe es auch ich verstanden

mase · 8. Dezember 2012

FireFly
Das Fixen des Burn-Plugins hat bei mir nicht funktioniert.
So sieht es jetzt aus:

Code

if (!PmtFound) {
                                    	if ( Pid == 0)
#if VDRVERSNUM < 10733
                    	else if (Pid == PatPmtParser.PmtPid())
#else
                    	else if (PatPmtParser.IsPmtPid(Pid))
#endif
                                    	else if (Pid == PatPmtParser.PmtPid())
                                            	PatPmtParser.ParsePmt(DataPtr, TS_SIZE);
                                    	else if (PatPmtParser.GetVersions(PatVersion, PmtVersion)) {
                                            	PmtFound = true;

Alles anzeigen

Aber dann dieser Fehler:

Code

scanner.c:410:25: error: expected primary-expression before ‘else’
scanner.c:410:25: error: expected ‘;’ before ‘else’
scanner.c:417:111: error: ‘class cPatPmtParser’ has no member named ‘PmtPid’

[ANNOUNCE] VDR developer version 1.7.33

Jetzt mitmachen!

Teilen