Hello,
I see errors like the below on every VDR (2.0.6) startup and apparently exactly 30 minute intervals after that in syslog:
ERROR: invalid sat cable number in '[apparent binary junk]'
The binary junk varies, today it's been for example '<C0><C0>ۙ>^?' and '<C0>0<BE><A4><8F>^?' as shown by "less". Any ideas what would be causing this or if I could do something to help debug this further?
On Thu, Apr 17, 2014 at 3:22 PM, Klaus Schmidinger Klaus.Schmidinger@tvdr.de wrote:
Sent in PM.
# grep DeviceBondings /etc/vdr/setup.conf DeviceBondings = 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
This is a DVB-C only system BTW (one FF and two budget cards).
On 17.04.2014 15:13, Ville Skyttä wrote:
From your log:
Apr 17 16:03:21 vdr[16019]: [16019] probing /dev/dvb/adapter0/frontend0 Apr 17 16:03:21 vdr[16019]: [16019] creating cDvbDevice Apr 17 16:03:21 vdr[16019]: [16019] new device number 1 Apr 17 16:03:21 vdr[16019]: [16019] frontend 0/0 provides DVB-C with QAM16,QAM32,QAM64,QAM128,QAM256 ("ST STV0297 DVB-C") Apr 17 16:03:21 vdr[16019]: [16019] probing /dev/dvb/adapter1/frontend0 Apr 17 16:03:21 vdr[16019]: [16019] creating cDvbDevice Apr 17 16:03:21 vdr[16019]: [16019] new device number 2 Apr 17 16:03:21 vdr[16019]: [16019] frontend 1/0 provides DVB-C with QAM16,QAM32,QAM64,QAM128,QAM256 ("ST STV0297 DVB-C") Apr 17 16:03:21 vdr[16019]: [16019] probing /dev/dvb/adapter2/frontend0 Apr 17 16:03:21 vdr[16019]: [16019] creating cDvbDevice Apr 17 16:03:21 vdr[16019]: [16019] new device number 3 Apr 17 16:03:21 vdr[16019]: [16019] frontend 2/0 provides DVB-C with QAM16,QAM32,QAM64,QAM128,QAM256 ("VLSI VES1820 DVB-C") Apr 17 16:03:21 vdr[16019]: [16019] found 3 DVB devices Apr 17 16:03:21 vdr[16019]: [16019] initializing plugin: softhddevice (0.6.1rc1): A software and GPU emulated HD device Apr 17 16:03:21 vdr[16019]: [16019] new device number 9
What looks a little strange here is the gap between device number 3 and 9. Maybe this causes some misbehavior in handling device bonding?
Klaus
On Thu, Apr 17, 2014 at 4:23 PM, Klaus Schmidinger Klaus.Schmidinger@tvdr.de wrote:
Dunno. I haven't told softhddevice to use any particular device number nor do I know if it's possible to do that. I've just configured it to set itself as the primary device.
But are "sat cable" and "device bonding" valid concepts on DVB-C in the first place? The "sat" smells like DVB-S to me...
On 17.04.2014 16:09, Ville Skyttä wrote:
These are purely sat related. I don't believe that the errors come from any tuning code, since actual device bonding is only done for DVB-S devices (see cDvbDevice::Bond()).
Does this error occur if you make any changes to the setup? Like changing the OSD language or anything else that would cause the setup.conf file to be written.
Klaus
Hi,
I had exactly the same errors on my VDR (2.1.6):
ERROR: invalid sat cable number in '°$Q‘
In my case the „binary junk“ is always °$Q, and the message appears also in a 30 min interval.
After deactivating/removing the naludump patch, I can’t find the messages in the logs anymore. But this is just a guess and I don’t know if this is really related….
Am 17.04.2014 um 13:07 schrieb Ville Skyttä ville.skytta@iki.fi:
On Thu, Apr 17, 2014 at 6:57 PM, Alexander Kniwel vdr-mailinglist@kniwel.net wrote:
Bingo, same thing here. Rebuilding VDR without the NALU dump patch gets rid of the error -- if the patch is in, it doesn't seem to make a difference if it's enabled in settings or not, the error is always there in syslog. Cc'ing patch author (@Udo: see below).
Ville
On Thu, Apr 17, 2014 at 1:28 PM, Ville Skyttä ville.skytta@iki.fi wrote:
naludump
How much disk space do you actually save using that?
Am 17.04.2014 22:28, schrieb Ville Skyttä:
Hmmm, thats weired. I don't have such errors on my system, and even more strange, minimizing risks was one of the design goals of the patch, thats why the nalu filter is right before the disk writer, thus without an ongoing recording, the patch does nothing.
The filter itself also makes sure that no data can be accidentally dropped, by only dropping TS packets that only contain FF bytes and only within nalu fill packets.
Is this the original patch from my website? ( http://www.udo-richter.de/vdr/naludump.html )
Are there any hints that this behavior started with a certain VDR version?
Ok, some leaning out of the window: The patch adds an entry to config.h. The message origins from the config.h string DeviceBondings. Maybe not all parts of VDR (or plugins) were compiled against the patched config.h? This would cause an mis-aligned access to the string.
Cheers,
Udo
PS: Unfortunately, I'm offline for two weeks, starting Friday.
On Thu, Apr 24, 2014 at 4:07 AM, Udo Richter udo_richter@gmx.de wrote:
Is this the original patch from my website? ( http://www.udo-richter.de/vdr/naludump.html )
Yes.
All plugins I have were built without the patch as it wasn't available for 2.0.6 at the time I upgraded to 2.0.6, and later when it became available I rebuilt only VDR with it. Looks like epgsearch took a hit that caused it to somehow start to emit these messages (as the thread ids in my logs and the occurrence every 30 minutes suggested), rebuilding it caused the messages to go away. Thanks a bunch, I'll go rebuild the rest of the plugins. Who knows, maybe this is also the reason for the EIT related crash I reported lately.
-
Alexander Kniwel -
Klaus Schmidinger -
Udo Richter -
VDR User -
Ville Skyttä -
Wolfgang Rohdewald