ATSC is the standard for OTA broadcast in the US now. It would be nice if support could be built into vdr now. The plugin for getting eit data and scanning for channels hasn't been updated in 2 years. It still has problems. on my x64 system, it seg faults most of the time when trying to scan for channels. It's more of a fluke that when it does work. And boradcasters don't follow the standards or something because I often don't have guide data when a 60$ converter box is able to find guide data.
It would be nice to have its functions moved to VDR and then just dump the plugin. It served it's purpose when ATSC was just starting to be used, but it's time to build it in instead of it being an after thought.
On 25.08.2012 04:04, Timothy D. Lenz wrote:
I don't think that problems would be fixed any better if this were part of the official VDR code. If the original author no longer maintains the code, somebody else should take over and fix it. VDR is mainly written for the *DVB* standard. Anything else should be external.
Klaus
On 25 August 2012 20:54, Timothy D. Lenz tlenz@vorgon.com wrote:
The problem here in the US is, DVB is not a standard for anything.
I'm guessing Klaus' problem here is that he doesn't live in the US so can't access ATSC broadcasts for testing, so it doesn't really make sense for him to attempt to maintain it in VDR core :)
Where is the current home for the ATSC plugin and who is/was the original maintainer? Ideally it needs a US-based maintainer, but (failing that) it should at least be migrated to somewhere more public (e.g., github or vdr-developers) so that bugs/issues can be tracked.
On Tue, Aug 28, 2012 at 8:05 AM, Dominic Evans oldmanuk@gmail.com wrote:
It would be nice if it were moved to vdr-developers. I don't think the author would even have a problem with that. The real drawback for NA is that while there are plenty of users, there's practically no coders here. The ones I know have either left VDR, or dvb altogether. Thankfully there has been some EU coders willing to throw us a bone and help out occasionally. With their help, and Klaus, NA VDR is far less painful today that in the past. :)
Yes, and there are programs that can capture part of a stream to a file to examine. So you don't need access to the stream to see where the broadcasters are failing to follow the FCC set standards. I think Dvbsnoop is one and I have compiled, though I only used it once or twice several years ago.
I think the plugin dev once said it is likely that the reason I don't get data sometimes is because there is some flag to set that there is data and they don't set it. The converter boxes and TV's ignore the flag and go look for the data.
On 8/28/2012 9:53 AM, VDR User wrote:
I suspect he ether got too busy to work on it anymore or just got tired of of it. He put out several nice plugins in a short time back when the US switched to ATSC.
On 8/28/2012 8:05 AM, Dominic Evans wrote:
The crashing problem would be better address by making it part of VDR. I am trying to make scripts to use Schedules Direct because even if VDR was picking up what the broadcasters send, the broadcasters themselves are unreliable and half assed at sending eit. But if the seg fault when trying to scan for new channels where fixed, that would help.
On 8/25/2012 2:42 AM, Klaus Schmidinger wrote:
On 28 Aug 2012, at 20:58, "Timothy D. Lenz" tlenz@vorgon.com wrote:
The crashing problem would be better address by making it part of VDR. I am trying to make scripts to use Schedules Direct because even if VDR was picking up what the broadcasters send, the broadcasters themselves are unreliable and half assed at sending eit. But if the seg fault when trying to scan for new channels where fixed, that would help.
Do you have a core file from when it segfaulted in the past? Or, can you reproduce it and capture one?
I don't mess with this enough to remember the steps for making the dumps, but making it crash is as easy as telling it to scan for channels. So if you want to put up the steps to get the data... :)
I'm using Debian x64 and I use putty/winscp to work with it.
On 8/28/2012 1:11 PM, Dominic Evans wrote:
Just did a crash to grab what is in the logs:
/var/log/ syslog: Aug 29 13:57:01 x64VDR vdr: [9106] ATSC Scanner thread started (pid=20976, tid=9106) Aug 29 13:57:01 x64VDR kernel: ATSC Scanner[9106]: segfault at 7f9ca8000108 ip 00007f9ca8000108 sp 00007f9c9dc9cbc8 error 15
messages: Aug 29 13:57:01 x64VDR kernel: ATSC Scanner[9106]: segfault at 7f9ca8000108 ip 00007f9ca8000108 sp 00007f9c9dc9cbc8 error 15
kern.log Aug 29 13:57:01 x64VDR kernel: ATSC Scanner[9106]: segfault at 7f9ca8000108 ip 00007f9ca8000108 sp 00007f9c9dc9cbc8 error 15
On the tv it just locks up. have to restart vdr
On 8/28/2012 1:11 PM, Dominic Evans wrote:
Hi Timothy,
On 29 August 2012 22:01, Timothy D. Lenz tlenz@vorgon.com wrote:
There's not really much to see from this, apart from showing us that it is the ATSC Scanner code itself causing the segfault :)
You'll need to recompile the plugin yourself to preserve debug symbols (any debian packaged version will likely be stripped of symbols) and then copy it into /var/lib/vdr/plugins (or wherever your vdr is configured to store plugins)
Then you'll need to make sure core files are generated, e.g., by adding `ulimit -c unlimited` before the call to /usr/bin/vdr in /usr/sbin/runvdr (again assuming you're using debian packages).
Then you should get core files generated if a segfault occurs.
-
Dominic Evans -
Klaus Schmidinger -
Timothy D. Lenz -
VDR User