Re: [vdr] get a segmentation fault when starting vdr (backtrace included)
On Fri, Nov 30, 2012 at 11:00:52AM +0100, Dieter Bloms wrote:
I changed it this way:
--snip--
32 bool tComponent::FromString(const char *s)
33 {
34 unsigned int Stream, Type;
35 description = NULL;
36 int n = sscanf(s, %X %02X %7s %a[^\n], Stream, Type, language,
description); // 7 = MAXLANGCODE2 - 1
37 esyslog(dbloms: \%X\ \%02X\ \%7s\ \%a\, Stream, Type,
language, description);
38
39 if (n != 4 || isempty(description)) {
40 free(description);
41 description = NULL;
42 }
43 stream = Stream;
44 type = Type;
45 return n = 3;
46 }
--snip--
IMHO the %a should become %s in esyslog() whereas in sscanf() the %a should
become %as
for the GNU extension of dynamically allocating string conversions.
Werner
--
Having a smoking section in a restaurant is like having
a peeing section in a swimming pool. -- Edward Burr
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] get a segmentation fault when starting vdr (backtrace included)
On Fri, Nov 30, 2012 at 12:08:53PM +0100, Dieter Bloms wrote:
Hi Werner,
--snip--
25 cString tComponent::ToString(void)
26 {
27 char buffer[256];
28 snprintf(buffer, sizeof(buffer), %X %02X %s %s, stream, type,
language, description ? description : );
29 return buffer;
30 }
31
32 bool tComponent::FromString(const char *s)
33 {
34 unsigned int Stream, Type;
35 description = NULL;
36 int n = sscanf(s, %X %02X %7s %as[^\n], Stream, Type, language,
description); // 7 = MAXLANGCODE2 - 1
37 esyslog(dbloms: \%X\ \%02X\ \%7s\ \%s\, Stream, Type,
language, description);
38
39 if (n != 4 || isempty(description)) {
40 free(description);
41 description = NULL;
42 }
43 stream = Stream;
44 type = Type;
45 return n = 3;
46 }
--snip--
and get a core dump with this:
--snip--
vdrservernew:/tmp# gdb --core /tmp/core /usr/local/bin/vdr
GNU gdb (GDB) 7.5
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as x86_64-unknown-linux-gnu.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /usr/local/bin/vdr...done.
[New LWP 8986]
[New LWP 8985]
[New LWP 8987]
[Thread debugging using libthread_db enabled]
Using host libthread_db library /lib/libthread_db.so.1.
Core was generated by `/usr/local/bin/vdr --config=/etc/vdr
--epgfile=/tmp/epg.data --grab=/dev/shm --'.
Program terminated with signal 11, Segmentation fault.
#0 0x6b2476b263b3 in strnlen () from /lib/libc.so.0.9.32
(gdb) bt
#0 0x6b2476b263b3 in strnlen () from /lib/libc.so.0.9.32
#1 0x6b2476b1ff56 in ?? () from /lib/libc.so.0.9.32
#2 0x6b2476b1d5dc in vsnprintf () from /lib/libc.so.0.9.32
#3 0x6b2476b14c29 in vsyslog () from /lib/libc.so.0.9.32
#4 0x0052e510 in syslog_with_tid (priority=3, format=0x551ab8
dbloms: \%X\ \%02X\ \%7s\ \%s\) at tools.c:40
#5 0x004a1e4e in FromString (s=optimized out, this=0x3dabc20) at
epg.c:37
#6 cComponents::SetComponent (this=optimized out, Index=optimized out,
s=s@entry=0x3d2 1 01 deu 4:3) at epg.c:84
#7 0x004a4163 in cEvent::Parse (this=0x3d9f4d0, s=optimized out)
at epg.c:498
#8 0x004e9f16 in cRecordingInfo::Read (this=0x3da8640,
f=f@entry=0x3d9f840) at recording.c:468
#9 0x004eb553 in cRecording::cRecording (this=0x3da05c0,
FileName=0x3d8aa7c Sex_and_the_City_2/2012-11-19.20.10.27-0.rec) at
recording.c:723
#10 0x004ecf21 in cRecordings::ScanVideoDir (this=0x7fe880
Recordings, DirName=0x3d9d4c0 /remote/vdr/Sex_and_the_City_2,
Foreground=false, LinkLevel=0) at recording.c:1165
#11 0x004ed39c in cRecordings::ScanVideoDir (this=0x7fe880
Recordings, DirName=0x3d83a20 /remote/vdr, Foreground=false, LinkLevel=0)
at recording.c:1180
#12 0x005269be in cThread::StartThread (Thread=0x7fe8a0
Recordings+32) at thread.c:262
#13 0x6b247844a406 in start_thread () from /lib/libpthread.so.0.9.32
#14 0x6b2478442885 in clone () from /lib/libpthread.so.0.9.32
#15 0x in ?? ()
(gdb)
--snip--
Maybe some more checks are required as if n != 4 this could be that one of the
variables are not used and therefore not initialized.
Before sscanf() this could be a `memset(language, 0, sizeof(language));' or more
simple a `*language = 0;' depending on the type of language. Also the code
if (n != 4 || isempty(description)) {
free(description);
description = NULL;
}
could become
if (n != 4 || isempty(description)) {
if (description)
free(description);
description = NULL;
}
as well as the line
esyslog(dbloms: \%X\ \%02X\ \%7s\ \%s\, Stream, Type, language,
description);
may look like
esyslog(dbloms: \%X\ \%02X\ \%7s\ \%s\, Stream, Type, language,
description ? description : );
Werner
--
Having a smoking section in a restaurant is like having
a peeing section in a swimming pool. -- Edward Burr
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] IS there a working UPnP-AV/DLNA support for VDR?
On Thu, Feb 09, 2012 at 08:45:16PM +0100, Denis Loh wrote: Hi, i am still working on it. However, progess is very slow, sorry. Nevertheless, you cannot control the vdr the way you expected. An default DLNA server only allows you to show media files (and live TV) on your DLNA or UPnP capable device. You cannot schedule recordings, start/stop the server or do anything beside watching media, unfortunatelly. DLNA does not specify those features in its current version 1.5. It will be supported in 2.0 and above, however it may take some years that devices implementors will support them as they are mostly optional. I even haven't seen any TV device which supports the tuner service capability of a DLNA media server very well (In this case, you would be able to switch channels by pressing a channel number or by chan-up/chan-down). Additionally, it won't be possible to show any EPG or OSD on an DLNA device without work-a-rounds, like transcoding EPG/OSD into an MPEG stream. There is a possibility to transmit text based date, but this is not being supported by any TV device I know. Well, DLNA sounds perfect when you don't expect too much: you may exchange media from one device to another. You can share media of a certain device to others and let them play it. But you cannot play files which are not supported by the device, even though it may play the files directly for instance via USB. Sounds ridiculous, but works as designed. I work on an work-a-round to support scheduling records via browser navigation. But, this is not very user friendly because you have to play every command and simulate a media file to the TV. Every DLNA server must support a web page where the server allows to show additional information. I will use live among others in this case, as it seems to do everything needed. I hope this will help, somehow. Please let me know, if you miss something to be supported. Hmmm ... maybe HbbTV would be an option. Let's say for handling the VDR. Otherwise I would like to avoid softdevice as well as expensive full featured HDTV DVB-cards. Werner -- AC3 loop through sound card http://bitstreamout.sourceforge.net/ Howto http://www.vdr-portal.de/board/thread.php?threadid=1958 -- Having a smoking section in a restaurant is like having a peeing section in a swimming pool. -- Edward Burr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] bitstreamout plugin and VDR 1.7.17
On Sun, Apr 03, 2011 at 12:53:43AM +0200, Tobi wrote: Hi! Does the bitstreamout plugin still make sense for VDR 1.7.17? Upstream has been dead for about 3 years now and I'm considering to remove this plugin from the Debian archive. As I've no time to support my plugin, I'd like to ask if bitstreamout does compile and work together with VDR 1.7.17? Also is there any user which is able to do further work on the bitstreamout plugin. I'll be happy to add her/him to the developers list at sourceforge :) Werner -- AC3 loop through sound card http://bitstreamout.sourceforge.net/ -- Having a smoking section in a restaurant is like having a peeing section in a swimming pool. -- Edward Burr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] ts record (was - no channel update on vdr 1.7.0)
On Fri, May 23, 2008 at 04:42:06PM +0200, Klaus Schmidinger wrote: On 05/23/08 13:11, Goga777 wrote: Will the TS mods that Klaus is currently working on mean that the full stream of the transponder can be recorded? Or will the HW full-TS mod still be needed? The PES to TS switch will only change the way VDR records broadcasts and performs live viewing. There will be no more TS to PES conversion. VDR will still record separate programmes, though. It won't record the entire TS. is a lot of vdr-code need patch for this ? It's not too much, but at core locations and requires a lot of testing and debugging. OK ... for replaying the TS stuff on a FF DVD card you need a simple remuxer which does TS - PES with max. 2048 bytes per frame, do you? Werner -- Having a smoking section in a restaurant is like having a peeing section in a swimming pool. -- Edward Burr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card AV sync problems, possible fix to VDR (fwd)
On Sat, Mar 15, 2008 at 03:12:49PM +0100, Halim Sahin wrote: Hi Werner and List, On Mi, Mär 07, 2007 at 04:36:12 +0100, Dr. Werner Fink wrote: Beside a small problem of Video underruns during change from AC3 to Mpeg-Audio and at the start of a replay, I see no problems. At least the problem with broken Mpeg-Audio frames are gone. Hopefully I've something ready at this evening :^) Is this the mentioned firmware? http://www.suse.de/~werner/test_av-f22623.tar.bz2 What is the current status of the dvb firmware? Are you planning to release a new version? I'm currently very busy with my little daughter most free time but I'm also working on the firmware. It has taken some time and will take some time. Werner -- AC3 loop through sound card http://bitstreamout.sourceforge.net/ Howto http://www.vdr-portal.de/board/thread.php?threadid=1958 -- Having a smoking section in a restaurant is like having a peeing section in a swimming pool. -- Edward Burr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card AV sync problems, possible fix to VDR (fwd)
On Sun, Mar 04, 2007 at 12:42:11PM +, Morfsta wrote: Hi Werner, Were there problems? Beside a small problem of Video underruns during change from AC3 to Mpeg-Audio and at the start of a replay, I see no problems. At least the problem with broken Mpeg-Audio frames are gone. Hopefully I've something ready at this evening :^) Werner On 2/23/07, Dr. Werner Fink [EMAIL PROTECTED] wrote: On Thu, Feb 22, 2007 at 06:18:11PM +, Morfsta wrote: Hi Werner, Any idea when you will be able to release the new firmware for testing? I'm just testing the stuff in real live on my productions system ;) Knock on wood that this stays stable ... Werner -- AC3 loop through sound card http://bitstreamout.sourceforge.net/ Howto http://www.vdr-portal.de/board/thread.php?threadid=1958 -- Having a smoking section in a restaurant is like having a peeing section in a swimming pool. -- Edward Burr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card AV sync problems, possible fix to VDR (fwd)
On Thu, Feb 22, 2007 at 06:18:11PM +, Morfsta wrote: Hi Werner, Any idea when you will be able to release the new firmware for testing? I'm just testing the stuff in real live on my productions system ;) Knock on wood that this stays stable ... Werner -- Having a smoking section in a restaurant is like having a peeing section in a swimming pool. -- Edward Burr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR recording speeds up during playback
On Fri, Feb 23, 2007 at 12:12:18AM +0200, Tero Siironen wrote: I'm posting this now on this list, because got no reaction from dvb-list. I noticed a weird problem with last weeks Mythbusters episode VDR recording. The playback suddenly speeded up like fastforward and it is repeatable. I've seen this once earlier also, but thought that it was caused by bad reception, but this time the were no visible errors on the recording. Here's the clip (22MB): http://kotisivu.suomi.net/izero/mythbusters.tar Tested with VDR 1.4.5 and firmware versions 261a, 261f, 2622 and F12623 testversion (normally in use). Not repeatable when played with VLC on OS X. Does play perfect with my current working version of the firmware, please be patient ... Werner -- Having a smoking section in a restaurant is like having a peeing section in a swimming pool. -- Edward Burr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card AV sync problems, possible fix to VDR (fwd)
On Wed, Feb 21, 2007 at 11:12:43PM +0100, Reinhard Nissl wrote: Actually, I don't know how this is done in the case of a FF card and what the firmware has to do in this regard. A guess -- which could explain the issues you see -- would be that sync is not maintained continuously. So after having maintained sync for some time, audio and video frames are simply taken out of some FIFOs at a constant rate and presented to the user -- this should keep audio and video in sync as originally maintained. But when then for example an audio frame gets lost due to a lost TS packet, audio and video get out of sync as the lost packet brakes filling the FIFOs at a constant rate. When you try to reproduce this effect by seeking back in the recording, then sync is maintained actively and you don't see this issue again at that position in the recording. If the resulting Mpeg-Audio stream is broken in such a way that the HW-Decoder runs into trouble from which it can not recover the Audio HW_buffer gets emptied very fast which .. in fact .. results in a silent but very fast video sequence. For the next firmware I've added a dectection of such an unrecoverable audio decoder error to restart the audio decoder as fast as possible. Btw: With xine and mplayer I hear a short noise and nothing happen with the running picture. Maybe the mplay software decoder its self has some checking about the Mpeg-Audio stream and the AV synchronization does not depend on the audio PTS. Werner -- Having a smoking section in a restaurant is like having a peeing section in a swimming pool. -- Edward Burr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
