[ANNOUNCE] VDR developer version 1.7.20

Das hat das Aufnahmeproblem bei mir gelöst.

Danke Klaus

Hi,
Ich hatte das Problem auch, aber nicht bemerkt da ich auf SKY HD keine Aufnahmen getestet hatte.
Danke an Klaus für den Workaround, es läuft jetzt.
Was ein newPayload = false; ausmachen kann

Zitat von kls

Kannst du bitte als schnellen Versuch mal folgendes probieren?

Diff

--- remux.c     2011/08/15 09:50:14     2.58
+++ remux.c     2011/08/19 15:33:26
@@ -974,8 +974,10 @@
                                      payloadUnitOfFrame = (payloadUnitOfFrame + 1) % -framesPerPayloadUnit;
                                      if (payloadUnitOfFrame != 0 && independentFrame)
                                         payloadUnitOfFrame = 0;
-                                     if (payloadUnitOfFrame)
+                                     if (payloadUnitOfFrame) {
+                                        newPayload = false;
                                         newFrame = false;
+                                        }
                                      }
                                   if (framesPerPayloadUnit <= 1)
                                      scanning = false;

Alles anzeigen

Klaus

Sieht gut aus, eine kurze Aufnahme auf Vox HD hat geklappt.

Danke!!

Es gibt Updates für Osdserver und für hard link cutter für VDR-1.7.20:

http://www.udo-richter.de/vdr/patches.html#hlcutter
- Fix reject

http://www.udo-richter.de/vdr/osdserver.html
- Fix Message-Kommando, wird in VDR-1.7.20 verschluckt
- Warnings behoben, Makefile aktualisiert

---------------------------------------------------------------------------

Zitat von clausmuus

Mir war grad ne Idee gekommen. Ich konnte den Fehler nun näher einkreisen.
Der Fehler tritt nur dann auf, wenn in der setup.conf der Wert "InitialChannel" nicht definiert ist, wenn man also z.B. mit ner leeren setup.conf startet.

Das ist es. Allerdings geht der Fehler auf die ursprüngliche Änderung aus 1.7.19 zurück:

Zitat

The initial channel is now stored by the channel ID in the setup.conf file, in
order to avoid problems in case channels are reordered or deleted (reported by
Lars Bläser).

Seit dem repräsentiert ein cString den InitialChannel, und im Fall einer leeren setup.conf ist es unglücklicherweise ein NULL-String. Ob das eine gute Idee war, dass Klaus' String-Klasse neben leeren Strings auch NULL-Strings kennt, ...

Anyway, versuch mal folgenden Patch:

--- menuitems.c.bak	2011-08-19 22:28:19.000000000 +0200
+++ menuitems.c	2011-08-19 22:29:03.000000000 +0200
@@ -810,7 +810,7 @@
 {
   channelID = ChannelID;
   noneString = NoneString;
-  cChannel *channel = Channels.GetByChannelID(tChannelID::FromString(*ChannelID));
+  cChannel *channel = *ChannelID ? Channels.GetByChannelID(tChannelID::FromString(*ChannelID)) : 0;
   dummyValue = channel ? channel->Number() : 0;
   Set();
 }

Gruß,

Udo

Zitat von Urig

--- menuitems.c.bak 2011-08-19 22:28:19.000000000 +0200
+++ menuitems.c 2011-08-19 22:29:03.000000000 +0200
@@ -810,7 +810,7 @@
{
channelID = ChannelID;
noneString = NoneString;
- cChannel *channel = Channels.GetByChannelID(tChannelID::FromString(*ChannelID));
+ cChannel *channel = *ChannelID ? Channels.GetByChannelID(tChannelID::FromString(*ChannelID)) : 0;
dummyValue = channel ? channel->Number() : 0;
Set();
}

Alles anzeigen

menuitems.c:727:98: error: conversion from 'cString' to 'bool' is ambiguous
tools.h:172:3: note: candidates are: cString::operator const char*() const
tools.h:171:3: note:                 cString::operator const void*() const

Vielleicht besser so?

cChannel *channel = (const char *)*ChannelID ? Channels.GetByChannelID(tChannelID::FromString(*ChannelID)) : 0;

Gerald

Hab's jetzt so gemacht:

--- config.c    2011/06/13 14:41:01     2.14
+++ config.c    2011/08/20 09:12:05     2.15
@@ -395,7 +395,7 @@
   CurrentChannel = -1;
   CurrentVolume = MAXVOLUME;
   CurrentDolby = 0;
-  // InitialChannel is initialized by constructor
+  InitialChannel = "";
   InitialVolume = -1;
   ChannelsWrap = 0;
   EmergencyExit = 1;

Klaus

Der config.c Patch läuft prima, aber der remux.c Patch produziert immer noch buffer Fehler + Emergeny Exit.

Ausserdem hab ich die Fehler bei SD Material (DVB-T) und nicht bei HD:

vdr: [6302] recording thread started (pid=2804, tid=6302)
vdr: [6302] frame type not in first packet of payload - buffering
vdr: [6302] ERROR: encountered new payload while buffering - dropping some data!
vdr: [6302] ERROR: too many bytes for frame type buffer (1128 > 940) - dropped 188 bytes
vdr: [6302] ERROR: too many bytes for frame type buffer (12972 > 940) - dropped 12032 bytes
vdr: [6302] initiating emergency exit

Das Log wird während 30 Sekunden ziemlich geflutet -> ist auf das wesentliche zusammen gekürzt.

Hat nach dem remux Patch wirklich niemand mehr Probleme?

Hi,

Zitat von Lou

Hat nach dem remux Patch wirklich niemand mehr Probleme?

Der Remux Patch behebt das Problem beim Aufnehmen von Sky HD - Sendern.
Dies ist dadurch definitiv behoben, wobei dies wohl nur ein workaround ist .
Deine Probleme habe ich hier nicht, im Log ist auch nichts zu sehen.

Hi,

ich habe das selbe Problem mit dem segfault wenn ich über das VDR OSD in den Menüpunkt Sonstiges wechsele. Das hier kommt im Log:

Aug 23 18:45:59 vdr kernel: [   44.078627] show_signal_msg: 6 callbacks suppressed
Aug 23 18:45:59 vdr kernel: [   44.078643] vdr[1447]: segfault at 0 ip 00007fbaeacead86 sp 00007fff0e45eb18 error 4 in libc-2.13.so[7fbaeac5f000+18a000]
Aug 23 18:46:09 vdr vdr: [1901] VDR version 1.7.20 started

Ich habe den Thread hier schon gelesen gabs dafür auch schon eine Lösung? Löst einer der Patches mein Problem?

Danke!

@swen4: der config.c Patch behebt diesen Segfault

rudirabbit: wenn du meine Logmeldungen mit den Posts in der vdr ML und auf Seite 1-2 vergleichst hab ich dieselben Fehlermeldungen wie ihr sie bei HD habt.

edit: mein Test vdr ist bis auf remux.c und config.c ungepatcht, also kein extension Patch.

Dann machs wie ich, nimm ein Stück (ca. 1 min) auf dem betreffenden Sender auf (mit 1.7.19 oder 18)
und lass die Aufnahme Klaus zukommen.

Hi

Zitat von Lou

edit: mein Test vdr ist bis auf remux.c und config.c ungepatcht, also kein extension Patch.

Ich habe den extension Patch zwar drin, glaube aber eher nicht das der bei dem Problem den Unterschied macht.
Der HD VDR hängt ja von vielen Faktoren ab. (Lib's, plugins)
Entferne z.b Testweise Plugins die nicht zwingend nötig sind.
mfg. Rudi

Wenn möglich lasst den Extensionpatch erstmal raus, ich bin bisher nicht dazugekommen die ganze Patches für 1.7.20 einzubauen.

Zitat

...
Dies ist dadurch definitiv behoben, wobei dies wohl nur ein workaround ist .

Ich hatte das eigentlich durchaus als Lösung gesehen, nicht nur als Workaround.
Es sei denn, es treten doch noch Probleme auf, die dadurch nicht behoben sind.
Hab' aber bisher noch kein Testmaterial bekommen.

Klaus

Trotz Einsatz des Patches für remux.c habe ich noch immer das u.a. Problem, welches aber bei mir nur mit vdr 1.7.20 und Hauppauge PVR-Karten 150/350 auftritt.

Mit DVB-T-/DVB-C-/DVB-S-Karten/-Kanälen habe ich das Problem nicht.

Testmaterial kann ich leider nicht liefern, da das Problem sofort beim Starten der Aufnahme losgeht und nur 0 Byte-Datei erzeugt.

Aug 29 22:07:44 pcneu vdr: [20700] record /video0/ZIB_2/2011-08-29.21.57.13-0.rec
Aug 29 22:07:44 pcneu vdr: [20700] creating directory /video0/ZIB_2
Aug 29 22:07:44 pcneu vdr: [20700] creating directory /video0/ZIB_2/2011-08-29.21.57.13-0.rec
Aug 29 22:07:44 pcneu vdr: [20700] recording to '/video0/ZIB_2/2011-08-29.21.57.13-0.rec/00001.ts'
Aug 29 22:07:44 pcneu vdr: [20700] creating directory /video4/ZIB_2
Aug 29 22:07:44 pcneu vdr: [20700] creating directory /video4/ZIB_2/2011-08-29.21.57.13-0.rec
Aug 29 22:07:44 pcneu vdr: [21580] recording thread started (pid=20700, tid=21580)
Aug 29 22:07:44 pcneu vdr: [20700] closing SVDRP connection
Aug 29 22:07:44 pcneu vdr: [21581] receiver on device 10 thread started (pid=20700, tid=21581)
Aug 29 22:07:44 pcneu vdr: [20700] connect from 127.0.0.1, port 49816 - accepted
Aug 29 22:07:45 pcneu vdr: [20700] closing SVDRP connection
Aug 29 22:07:45 pcneu vdr: [21582] PvrReadThread of /dev/video2 thread started (pid=20700, tid=21582)
Aug 29 22:07:45 pcneu vdr: [21580] frame type not in first packet of payload - buffering
Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame type buffer (2444 > 940) - dropped 2444 bytes
Aug 29 22:07:45 pcneu vdr: [21580] ERROR: encountered new payload while buffering - dropping some data!
Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame type buffer (2444 > 940) - dropped 2444 bytes
Aug 29 22:07:45 pcneu vdr: [21580] ERROR: encountered new payload while buffering - dropping some data!
Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame type buffer (2444 > 940) - dropped 2444 bytes
Aug 29 22:07:45 pcneu vdr: [21580] ERROR: encountered new payload while buffering - dropping some data!
Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame type buffer (2444 > 940) - dropped 2444 bytes
Aug 29 22:07:45 pcneu vdr: [21580] ERROR: encountered new payload while buffering - dropping some data!
Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame type buffer (2444 > 940) - dropped 2444 bytes
Aug 29 22:07:45 pcneu vdr: [21580] ERROR: encountered new payload while buffering - dropping some data!
Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame type buffer (2444 > 940) - dropped 2444 bytes
Aug 29 22:07:45 pcneu vdr: [21580] ERROR: encountered new payload while buffering - dropping some data!

Grüße,

Dirk

Gleichen Sender aufnehmen, mit einer alten Version, und dann einen Schnipsel an Klaus schicken.

Da ich die Datei aufgrund der Größe von ca. 111 MB wohl nicht per Mail schicken kann, brauch ich die Info,

wohin ich die Datei hochladen kann.

Grüße,

Dirk

Zitat von TEDDYXXL

Da ich die Datei aufgrund der Größe von ca. 111 MB wohl nicht per Mail schicken kann, brauch ich die Info,
wohin ich die Datei hochladen kann.

+ 1 - Falls jemand die Zugangsdaten hat bitte PN, dann lad ich ein Schnippsel hoch.

Moin!

Nehmt doch sonst den FTP-Server von Sigi...

Ich werde morgen versuchen, das Problem mal nachzuvollziehen.
Welche Version von pvrinput benutzt ihr?

Lars.

Ich nutze die git-Version des Plugins pvrinput.

Der Upload auf Sigi's FTP-Server ist durch.

Der Dateiname lautet: problemvdr1720pvr3sat00001.ts

Grüße,

Dirk