[vdr] *scanf %a, patches... (was: Re: get a segmentation fault when starting vdr (backtrace included))
In article <50ba09cc.2040...@flensrocker.de> you write:
>Am 30.11.2012 11:32, schrieb Gerald Dachs:
>> Am 2012-11-30 10:17, schrieb Lars Hanisch:
>>> Looks like the pointer returned by sscanf is not valid:
>>>
>>> 32: bool tComponent::FromString(const char *s)
>>> 33: {
>>> 34: unsigned int Stream, Type;
>>> 35: int n = sscanf(s, "%X %02X %7s %a[^\n]", &Stream, &Type,
>>> language, &description); // 7 = MAXLANGCODE2 - 1
>>> 36: if (n != 4 || isempty(description)) {
>>> 37: free(description);
>>> 38: description = NULL;
>>> 39: }
>>> 40: stream = Stream;
>>> 41: type = Type;
>>> 42: return n >= 3;
>>> 43: }
>>
>> From man sscanf:
>>
>>The GNU C library supports a nonstandard extension that causes the
>> library to
>>dynamically allocate a string of sufficient size for input strings
>> for the %s
>>and %a[range] conversion specifiers.
>>
>> This is the reason why it doesn't work with ulibc.
>
> Then there should be a malloc or something similiar for description:
>
>32: bool tComponent::FromString(const char *s)
>33: {
>34: unsigned int Stream, Type;
> description = malloc(strlen(s));
> description[0] = 0;
>35: int n = sscanf(s, "%X %02X %7s %a[^\n]", &Stream, &Type, language,
>&description); // 7 = MAXLANGCODE2 - 1
>36: if (n != 4 || isempty(description)) {
>37: free(description);
>38: description = NULL;
>39: }
>40: stream = Stream;
>41: type = Type;
>42: return n >= 3;
>43: }
>
> A check for description != NULL before the free call is not needed.
>
> But this is not the only place in the vdr code, where %a is used...
>
Btw FreeBSD has the same problem (no *scanf %a in libc), so you
could try taking the FreeBSD patches and replacing
#ifdef __FreeBSD__
by
#if defined(__FreeBSD__) || defined(__UCLIBC__)
in those parts handling %a here:
http://svnweb.freebsd.org/ports/head/multimedia/vdr/files/patch-vdr-1.7.28_FreeBSD?revision=300896&view=markup
A few plugins are affected too: (of those we have in FreeBSD ports)
eepg:
http://svnweb.freebsd.org/ports/head/multimedia/vdr-plugin-eepg/files/patch-eepg.c?revision=300896&view=markup
infosatepg:
http://svnweb.freebsd.org/ports/head/multimedia/vdr-plugin-infosatepg/files/patch-process.cpp?view=markup
ttxtsubs:
http://svnweb.freebsd.org/ports/head/multimedia/vdr-plugin-ttxtsubs/files/patch-ttxtsubschannelsettings.c?revision=300896&view=markup
HTH, :)
Juergen
PS: I think I never sent the FreeBSD patches to Klaus the last few
times I updated them, atm FreeBSD ports is behind again (still at
vdr 1.7.29), when I get around catching up to the latest version I
can send the updated patches if you are interested, Klaus? A few
more 1.7.29 patches are in here:
http://svnweb.freebsd.org/ports/head/multimedia/vdr/files/
(I think I did send FreeBSD patches to those plugin maintainers
that may still be active some time ago, haven't heard back from
many tho.)
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] *scanf %a, patches...
On Sun, Dec 02, 2012 at 02:19:44PM +0100, Klaus Schmidinger wrote:
> On 01.12.2012 21:14, Juergen Lock wrote:
> > In article <50ba09cc.2040...@flensrocker.de> you write:
> >> Am 30.11.2012 11:32, schrieb Gerald Dachs:
> >>> Am 2012-11-30 10:17, schrieb Lars Hanisch:
> >>>> Looks like the pointer returned by sscanf is not valid:
> >>>>
> >>>> 32: bool tComponent::FromString(const char *s)
> >>>> 33: {
> >>>> 34: unsigned int Stream, Type;
> >>>> 35: int n = sscanf(s, "%X %02X %7s %a[^\n]", &Stream, &Type,
> >>>> language, &description); // 7 = MAXLANGCODE2 - 1
> >>>> 36: if (n != 4 || isempty(description)) {
> >>>> 37: free(description);
> >>>> 38: description = NULL;
> >>>> 39: }
> >>>> 40: stream = Stream;
> >>>> 41: type = Type;
> >>>> 42: return n >= 3;
> >>>> 43: }
> >>>
> >>> From man sscanf:
> >>>
> >>> The GNU C library supports a nonstandard extension that causes
> >>> the library to
> >>> dynamically allocate a string of sufficient size for input
> >>> strings for the %s
> >>> and %a[range] conversion specifiers.
> >>>
> >>> This is the reason why it doesn't work with ulibc.
> >>
> >> Then there should be a malloc or something similiar for description:
> >>
> >> 32: bool tComponent::FromString(const char *s)
> >> 33: {
> >> 34: unsigned int Stream, Type;
> >> description = malloc(strlen(s));
> >> description[0] = 0;
> >> 35: int n = sscanf(s, "%X %02X %7s %a[^\n]", &Stream, &Type, language,
> >> &description); // 7 = MAXLANGCODE2 - 1
> >> 36: if (n != 4 || isempty(description)) {
> >> 37: free(description);
> >> 38: description = NULL;
> >> 39: }
> >> 40: stream = Stream;
> >> 41: type = Type;
> >> 42: return n >= 3;
> >> 43: }
> >>
> >> A check for description != NULL before the free call is not needed.
> >>
> >> But this is not the only place in the vdr code, where %a is used...
> >>
> > Btw FreeBSD has the same problem (no *scanf %a in libc), so you
> > could try taking the FreeBSD patches and replacing
> >
> > #ifdef __FreeBSD__
> >
> > by
> >
> > #if defined(__FreeBSD__) || defined(__UCLIBC__)
> >
> > in those parts handling %a here:
> >
> >
> > http://svnweb.freebsd.org/ports/head/multimedia/vdr/files/patch-vdr-1.7.28_FreeBSD?revision=300896&view=markup
> >
> > A few plugins are affected too: (of those we have in FreeBSD ports)
> >
> > eepg:
> >
> >
> > http://svnweb.freebsd.org/ports/head/multimedia/vdr-plugin-eepg/files/patch-eepg.c?revision=300896&view=markup
> >
> > infosatepg:
> >
> >
> > http://svnweb.freebsd.org/ports/head/multimedia/vdr-plugin-infosatepg/files/patch-process.cpp?view=markup
> >
> > ttxtsubs:
> >
> >
> > http://svnweb.freebsd.org/ports/head/multimedia/vdr-plugin-ttxtsubs/files/patch-ttxtsubschannelsettings.c?revision=300896&view=markup
> >
> > HTH, :)
> > Juergen
> >
> > PS: I think I never sent the FreeBSD patches to Klaus the last few
> > times I updated them, atm FreeBSD ports is behind again (still at
> > vdr 1.7.29), when I get around catching up to the latest version I
> > can send the updated patches if you are interested, Klaus?
>
> Well, in all honesty (and without meaning any offense or disrespect),
> I wouldn't like to have all these "#if ..." spread around the VDR source.
> For instance, things like a missing getline() function should not be
> patched right into the tools.c code, but rather be put into a separate
> file, maybe named oscompat.[hc]. In that file, depending on the OS in use,
> a local implementation of getline() could be implemented, and tools.c
> (like any other file that needs OS compatibility stuff) could just
> #include "oscompat.h" and the Makefile could link oscompat.o into
> the final executable.
>
> There are also some patches that don't, at first glance, look like they
> would be BSD specific, like those in plugin.c. Are these just a different
> way of handling things (and would this also work on Linux)? Or is this
> whole shebang handled differently in BSD?
>
Re: [vdr] *scanf %a, patches...
On Sun, Dec 02, 2012 at 08:58:31PM +0100, Juergen Lock wrote:
> On Sun, Dec 02, 2012 at 02:19:44PM +0100, Klaus Schmidinger wrote:
> > On 01.12.2012 21:14, Juergen Lock wrote:
> > > In article <50ba09cc.2040...@flensrocker.de> you write:
> > >> Am 30.11.2012 11:32, schrieb Gerald Dachs:
> > >>> Am 2012-11-30 10:17, schrieb Lars Hanisch:
> [...] And the tools.c patch for the
> cCharSetConv destructor looks like an actual bug, iconv_close()
> shouldn't be called with (iconv_t)-1.
>
Ah sorry that patch isn't in ports yet, and now that I think of it
it only occured when testing the epgfixer plugin which doesn't quite
work properly yet anyway. But I guess it wouldn't hurt applying
anyway so here it is:
--- tools.c.orig
+++ tools.c
@@ -842,7 +842,8 @@ cCharSetConv::cCharSetConv(const char *F
cCharSetConv::~cCharSetConv()
{
free(result);
- iconv_close(cd);
+ if (cd != (iconv_t)-1)
+ iconv_close(cd);
}
void cCharSetConv::SetSystemCharacterTable(const char *CharacterTable)
Thanx again, :)
Juergen
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Device bonding
Hi!
Now that I have a spare DVB-S2 tuner (TechniSat SkyStar USB HD
(adapter2); the others on this box are atm Hauppauge Nova-TD model
1172 (adapter 0+1) and TechnoTrend S2-3600 (adapter3) - all USB) I
decided to play with vdr device bonding. I discovered three things:
(still using vdr 1.7.29, I know I should upgrade... :)
1. The LNB setup OSD menu causes bonding to fail (it's trying to
bond a DVB-T tuner) if I set the two DVB-S2 tuners as "connected
to sat cable 1"; it works with "sat cable 2". Maybe it somehow
thinks of (one of?) the DVB-T tuner(s) as cable 1 too?
2. The infosatepg plugin doesn't check MaySwitchTransponder() and thus
grabs a bonded device when it shouldn't, I just patched that in the
FreeBSD port: (plugin maintainer Cc'd)
http://svnweb.freebsd.org/ports/head/multimedia/vdr-plugin-infosatepg/files/patch-infosatepg.cpp?r1=300896&r2=312357
3. Running with these four tuners (dual DVB-T and the bonded two DVB-S2)
I get two different deadlocks waiting for cDvbTuner::bondMutex
after live viewing a DVB-T(!) channel for longer (OSD doesn't
react anymore and attaching gdb reveals two threads waiting for
bondMutex) - the following two changes make it work but there
probably is a better fix: (patch may apply with offsets; one
of the problems I think is a lock order reversal with cDvbTuner::mutex
and bondMutex when cDvbTuner::SetChannel calls back into itself
with bondMutex held.)
--- dvbdevice.c.orig
+++ dvbdevice.c
@@ -476,8 +476,10 @@ void cDvbTuner::SetChannel(const cChanne
t->SetChannel(NULL);
}
}
-else if (strcmp(GetBondingParams(Channel),
BondedMaster->GetBondingParams()) != 0)
+else if (strcmp(GetBondingParams(Channel),
BondedMaster->GetBondingParams()) != 0) {
+ bondMutex.Unlock();
BondedMaster->SetChannel(Channel);
+ }
}
cMutexLock MutexLock(&mutex);
if (!IsTunedTo(Channel))
@@ -761,7 +773,12 @@ bool cDvbTuner::SetFrontend(void)
tone = SEC_TONE_ON;
}
int volt = (dtp.Polarization() == 'V' || dtp.Polarization() == 'R') ?
SEC_VOLTAGE_13 : SEC_VOLTAGE_18;
-if (GetBondedMaster() != this) {
+#if 1
+if (bondedTuner && !bondedMaster)
+#else
+if (GetBondedMaster() != this)
+#endif
+ {
tone = SEC_TONE_OFF;
volt = SEC_VOLTAGE_13;
}
Thanx,
Juergen
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Device bonding
On Sat, Feb 16, 2013 at 04:46:36PM +0100, Juergen Lock wrote:
> Hi!
>
> [...]
> 3. Running with these four tuners (dual DVB-T and the bonded two DVB-S2)
>I get two different deadlocks waiting for cDvbTuner::bondMutex
>after live viewing a DVB-T(!) channel for longer (OSD doesn't
>react anymore and attaching gdb reveals two threads waiting for
>bondMutex) - the following two changes make it work but there
>probably is a better fix: (patch may apply with offsets; one
>of the problems I think is a lock order reversal with cDvbTuner::mutex
>and bondMutex when cDvbTuner::SetChannel calls back into itself
>with bondMutex held.)
>
> --- dvbdevice.c.orig
> +++ dvbdevice.c
> @@ -476,8 +476,10 @@ void cDvbTuner::SetChannel(const cChanne
>t->SetChannel(NULL);
>}
> }
> -else if (strcmp(GetBondingParams(Channel),
> BondedMaster->GetBondingParams()) != 0)
> +else if (strcmp(GetBondingParams(Channel),
> BondedMaster->GetBondingParams()) != 0) {
> + bondMutex.Unlock();
> BondedMaster->SetChannel(Channel);
> + }
> }
> cMutexLock MutexLock(&mutex);
> if (!IsTunedTo(Channel))
> @@ -761,7 +773,12 @@ bool cDvbTuner::SetFrontend(void)
> tone = SEC_TONE_ON;
> }
> int volt = (dtp.Polarization() == 'V' || dtp.Polarization() == 'R')
> ? SEC_VOLTAGE_13 : SEC_VOLTAGE_18;
> -if (GetBondedMaster() != this) {
> +#if 1
> +if (bondedTuner && !bondedMaster)
> +#else
> +if (GetBondedMaster() != this)
> +#endif
> + {
> tone = SEC_TONE_OFF;
> volt = SEC_VOLTAGE_13;
> }
>
Hmm looks like I posted too soon, the first hunk is actually too much
and causes other deadlocks (like when trying to play a DVB-S channel
via streamdev while live viewing another), so the patch I'm not testing
becomes:
--- dvbdevice.c.orig
+++ dvbdevice.c
@@ -761,7 +773,12 @@ bool cDvbTuner::SetFrontend(void)
tone = SEC_TONE_ON;
}
int volt = (dtp.Polarization() == 'V' || dtp.Polarization() == 'R') ?
SEC_VOLTAGE_13 : SEC_VOLTAGE_18;
-if (GetBondedMaster() != this) {
+#if 1
+if (bondedTuner && !bondedMaster)
+#else
+if (GetBondedMaster() != this)
+#endif
+ {
tone = SEC_TONE_OFF;
volt = SEC_VOLTAGE_13;
}
Sorry,
Juergen
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Device bonding
In article <5121fba4.2050...@tvdr.de> you write: >On 16.02.2013 16:46, Juergen Lock wrote: >> Hi! >> >> Now that I have a spare DVB-S2 tuner (TechniSat SkyStar USB HD >> (adapter2); the others on this box are atm Hauppauge Nova-TD model >> 1172 (adapter 0+1) and TechnoTrend S2-3600 (adapter3) - all USB) I >> decided to play with vdr device bonding. I discovered three things: >> (still using vdr 1.7.29, I know I should upgrade... :) >> >> 1. The LNB setup OSD menu causes bonding to fail (it's trying to >> bond a DVB-T tuner) if I set the two DVB-S2 tuners as "connected >> to sat cable 1"; it works with "sat cable 2". Maybe it somehow >> thinks of (one of?) the DVB-T tuner(s) as cable 1 too? > >What does the "Setup/LNB" menu look like on your system? >Does it list only the two DVB-S devices, or all four of them? >Which device numbers does it display? > >What does the "DeviceBondings = ..." line in setup.conf look like >in both cases (working/not working)? > working: Einstellungen - LNB DiSEqC benutzen: nein SLOF (MHz): 11700 Untere LNB-Frequenz (MHz): 9750 Obere LNB-Frequenz (MHz): 10600 Device 3 angeschlossen an Sat-Kabel:2 Device 4 angeschlossen an Sat-Kabel:2 -> DeviceBondings = 1 0 2 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 broken: Einstellungen - LNB DiSEqC benutzen: nein SLOF (MHz): 11700 Untere LNB-Frequenz (MHz): 9750 Obere LNB-Frequenz (MHz): 10600 Device 3 angeschlossen an Sat-Kabel:1 Device 4 angeschlossen an Sat-Kabel:1 -> DeviceBondings = 1 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 >You wrote that your DVB-S2 device is "adapter2". Does this mean it >is actually "adaper2/frontend0" and "adapter2/frontend1"? > No the other DVB-S2 tuner is adapter3 (TechnoTrend S2-3600), all four only have frontend0 no frontend1. >Have you appliead any patches to VDR? Currently the two patches belonging to the iptv and ttxtsubs plugins and my stb0899 signal strength patch, and of course the FreeBSD portability patches. >If so, what happens without them? I will have to check that later tho I guess they are unrelated... >Same for plugins. > I just started vdr with just the xineliboutput plugin (I don't have an ff card) and got the same DeviceBondings = 1 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 when setting both DVB-S2 tuners as ".. connected to sat cable 1". I wonder, could this be a result of me running vdr with only the DVB-S2 tuners once and the first 1 in DeviceBondings that I may have set then simply doesn't get reset when the first two tuners became DVB-T? >Klaus Thanx! Juergen ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Device bonding
On Sun, Feb 17, 2013 at 04:34:25PM +0100, Juergen Lock wrote:
> On Sat, Feb 16, 2013 at 04:46:36PM +0100, Juergen Lock wrote:
> > Hi!
> >
> > [...]
>
> > 3. Running with these four tuners (dual DVB-T and the bonded two DVB-S2)
> >I get two different deadlocks waiting for cDvbTuner::bondMutex
> >after live viewing a DVB-T(!) channel for longer (OSD doesn't
> >react anymore and attaching gdb reveals two threads waiting for
> >bondMutex) - the following two changes make it work but there
> >probably is a better fix: (patch may apply with offsets; one
> >of the problems I think is a lock order reversal with cDvbTuner::mutex
> >and bondMutex when cDvbTuner::SetChannel calls back into itself
> >with bondMutex held.)
> >
> > --- dvbdevice.c.orig
> > +++ dvbdevice.c
> > @@ -476,8 +476,10 @@ void cDvbTuner::SetChannel(const cChanne
> >t->SetChannel(NULL);
> >}
> > }
> > -else if (strcmp(GetBondingParams(Channel),
> > BondedMaster->GetBondingParams()) != 0)
> > +else if (strcmp(GetBondingParams(Channel),
> > BondedMaster->GetBondingParams()) != 0) {
> > + bondMutex.Unlock();
> > BondedMaster->SetChannel(Channel);
> > + }
> > }
> > cMutexLock MutexLock(&mutex);
> > if (!IsTunedTo(Channel))
> > @@ -761,7 +773,12 @@ bool cDvbTuner::SetFrontend(void)
> > tone = SEC_TONE_ON;
> > }
> > int volt = (dtp.Polarization() == 'V' || dtp.Polarization() ==
> > 'R') ? SEC_VOLTAGE_13 : SEC_VOLTAGE_18;
> > -if (GetBondedMaster() != this) {
> > +#if 1
> > +if (bondedTuner && !bondedMaster)
> > +#else
> > +if (GetBondedMaster() != this)
> > +#endif
> > + {
> > tone = SEC_TONE_OFF;
> > volt = SEC_VOLTAGE_13;
> > }
> >
>
> Hmm looks like I posted too soon, the first hunk is actually too much
> and causes other deadlocks (like when trying to play a DVB-S channel
> via streamdev while live viewing another), so the patch I'm not testing
.. I'm _now_ testing...
> becomes:
>
> --- dvbdevice.c.orig
> +++ dvbdevice.c
> @@ -761,7 +773,12 @@ bool cDvbTuner::SetFrontend(void)
> tone = SEC_TONE_ON;
> }
> int volt = (dtp.Polarization() == 'V' || dtp.Polarization() == 'R')
> ? SEC_VOLTAGE_13 : SEC_VOLTAGE_18;
> -if (GetBondedMaster() != this) {
> +#if 1
> +if (bondedTuner && !bondedMaster)
> +#else
> +if (GetBondedMaster() != this)
> +#endif
> + {
> tone = SEC_TONE_OFF;
> volt = SEC_VOLTAGE_13;
> }
>
Stupid typos...
Juergen
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Device bonding
In article <51234977.2040...@tvdr.de> you write:
>On 19.02.2013 01:48, Juergen Lock wrote:
>> On Mon, Feb 18, 2013 at 11:52:31PM +0100, Klaus Schmidinger wrote:
>>> On 18.02.2013 23:43, Juergen Lock wrote:
>>>> In article <5121fba4.2050...@tvdr.de> you write:
>>>>> On 16.02.2013 16:46, Juergen Lock wrote:
>>>>>> Hi!
>>>>>>
>>>>>> Now that I have a spare DVB-S2 tuner (TechniSat SkyStar USB HD
>>>>>> (adapter2); the others on this box are atm Hauppauge Nova-TD model
>>>>>> 1172 (adapter 0+1) and TechnoTrend S2-3600 (adapter3) - all USB) I
>>>>>> decided to play with vdr device bonding. I discovered three things:
>>>>>> (still using vdr 1.7.29, I know I should upgrade... :)
>>>>>>
>>>>>> 1. The LNB setup OSD menu causes bonding to fail (it's trying to
>>>>>> bond a DVB-T tuner) if I set the two DVB-S2 tuners as "connected
>>>>>> to sat cable 1"; it works with "sat cable 2". Maybe it somehow
>>>>>> thinks of (one of?) the DVB-T tuner(s) as cable 1 too?
>>>>>
>>>>> What does the "Setup/LNB" menu look like on your system?
>>>>> Does it list only the two DVB-S devices, or all four of them?
>>>>> Which device numbers does it display?
>>>>>
>>>>> What does the "DeviceBondings = ..." line in setup.conf look like
>>>>> in both cases (working/not working)?
>>>>>
>>>> working:
>>>>
>>>> Einstellungen - LNB
>>>>
>>>> DiSEqC benutzen: nein
>>>> SLOF (MHz): 11700
>>>> Untere LNB-Frequenz (MHz): 9750
>>>> Obere LNB-Frequenz (MHz): 10600
>>>> Device 3 angeschlossen an Sat-Kabel:2
>>>> Device 4 angeschlossen an Sat-Kabel:2
>>>>
>>>> ->
>>>> DeviceBondings = 1 0 2 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>>>> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>>>>
>>>> broken:
>>>>
>>>> Einstellungen - LNB
>>>>
>>>> DiSEqC benutzen: nein
>>>> SLOF (MHz): 11700
>>>> Untere LNB-Frequenz (MHz): 9750
>>>> Obere LNB-Frequenz (MHz): 10600
>>>> Device 3 angeschlossen an Sat-Kabel:1
>>>> Device 4 angeschlossen an Sat-Kabel:1
>>>>
>>>> ->
>>>> DeviceBondings = 1 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>>>> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>>>>
>>>>> You wrote that your DVB-S2 device is "adapter2". Does this mean it
>>>>> is actually "adaper2/frontend0" and "adapter2/frontend1"?
>>>>>
>>>>No the other DVB-S2 tuner is adapter3 (TechnoTrend S2-3600), all four
>>>> only have frontend0 no frontend1.
>>>>
>>>>> Have you appliead any patches to VDR?
>>>>
>>>>Currently the two patches belonging to the iptv and ttxtsubs plugins
>>>> and my stb0899 signal strength patch, and of course the FreeBSD
>>>> portability patches.
>>>>
>>>>> If so, what happens without them?
>>>>
>>>>I will have to check that later tho I guess they are unrelated...
>>>>
>>>>> Same for plugins.
>>>>>
>>>>I just started vdr with just the xineliboutput plugin (I don't have
>>>> an ff card) and got the same
>>>>
>>>> DeviceBondings = 1 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>>>> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>>>>
>>>> when setting both DVB-S2 tuners as ".. connected to sat cable 1".
>>>>
>>>>I wonder, could this be a result of me running vdr with only the DVB-S2
>>>> tuners once and the first 1 in DeviceBondings that I may have set then
>>>> simply doesn't get reset when the first two tuners became DVB-T?
>>>
>>> I'll have to further look into this, but you might be on to something here.
>>> Please stop VDR, set that line to
>>>
>>> DeviceBondings = 0 0 2 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>>> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>>>
>>> manually and restart VDR. Does it work then?
>>>
>> Yeah, looks like. (I should have tested that earlier... :)
>
>This should fix the device bondings once you open and confirm the Setup/LNB
>menu:
>
>--- menu.c 2013/02/17 13:17:49 2.79
>+++ menu.c 2013/02/19 09:33:26
>@@ -2965,6 +2965,8 @@
> for (int i = 0; i < cDevice::NumDevices(); i++) {
> if (cDevice::GetDevice(i)->ProvidesSource(cSource::stSat))
> Add(new cMenuEditIntItem(cString::sprintf(tr("Setup.LNB$Device
> %d connected to sat cable"), i + 1), &satCableNumbers.Array()[i], 0,
> NumSatDevices, tr("Setup.LNB$own")));
>+ else
>+satCableNumbers.Array()[i] = 0;
> }
> }
>
Yep, that fixed it. :)
Thanx again!
Juergen
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Device bonding
In article <51235356.60...@tvdr.de> you write:
>On 19.02.2013 11:19, Klaus Schmidinger wrote:
>> On 18.02.2013 23:51, Juergen Lock wrote:
>>> On Sun, Feb 17, 2013 at 04:34:25PM +0100, Juergen Lock wrote:
>>>> On Sat, Feb 16, 2013 at 04:46:36PM +0100, Juergen Lock wrote:
>>>>> Hi!
>>>>>
>>>>> [...]
>>>>
>>>>> 3. Running with these four tuners (dual DVB-T and the bonded two DVB-S2)
>>>>> I get two different deadlocks waiting for cDvbTuner::bondMutex
>>>>> after live viewing a DVB-T(!) channel for longer (OSD doesn't
>>>>> react anymore and attaching gdb reveals two threads waiting for
>>>>> bondMutex) - the following two changes make it work but there
>>>>> probably is a better fix: (patch may apply with offsets; one
>>>>> of the problems I think is a lock order reversal with cDvbTuner::mutex
>>>>> and bondMutex when cDvbTuner::SetChannel calls back into itself
>>>>> with bondMutex held.)
>>>>>
>>>>> --- dvbdevice.c.orig
>>>>> +++ dvbdevice.c
>>>>> @@ -476,8 +476,10 @@ void cDvbTuner::SetChannel(const cChanne
>>>>> t->SetChannel(NULL);
>>>>> }
>>>>> }
>>>>> -else if (strcmp(GetBondingParams(Channel),
>>>>> BondedMaster->GetBondingParams()) != 0)
>>>>> +else if (strcmp(GetBondingParams(Channel),
>>>>> BondedMaster->GetBondingParams()) != 0) {
>>>>> + bondMutex.Unlock();
>>>>> BondedMaster->SetChannel(Channel);
>>>>> + }
>>>>> }
>>>>>cMutexLock MutexLock(&mutex);
>>>>>if (!IsTunedTo(Channel))
>>>>> @@ -761,7 +773,12 @@ bool cDvbTuner::SetFrontend(void)
>>>>> tone = SEC_TONE_ON;
>>>>> }
>>>>> int volt = (dtp.Polarization() == 'V' || dtp.Polarization() ==
>>>>> 'R') ? SEC_VOLTAGE_13 : SEC_VOLTAGE_18;
>>>>> -if (GetBondedMaster() != this) {
>>>>> +#if 1
>>>>> +if (bondedTuner && !bondedMaster)
>>>>> +#else
>>>>> +if (GetBondedMaster() != this)
>>>>> +#endif
>>>>> + {
>>>>> tone = SEC_TONE_OFF;
>>>>> volt = SEC_VOLTAGE_13;
>>>>> }
>>>>>
>>>>
>>>> Hmm looks like I posted too soon, the first hunk is actually too much
>>>> and causes other deadlocks (like when trying to play a DVB-S channel
>>>> via streamdev while live viewing another), so the patch I'm not testing
>>>
>>> .. I'm _now_ testing...
>>>
>>>> becomes:
>>>>
>>>> --- dvbdevice.c.orig
>>>> +++ dvbdevice.c
>>>> @@ -761,7 +773,12 @@ bool cDvbTuner::SetFrontend(void)
>>>> tone = SEC_TONE_ON;
>>>> }
>>>> int volt = (dtp.Polarization() == 'V' || dtp.Polarization() ==
>>>> 'R') ? SEC_VOLTAGE_13 : SEC_VOLTAGE_18;
>>>> -if (GetBondedMaster() != this) {
>>>> +#if 1
>>>> +if (bondedTuner && !bondedMaster)
>>>> +#else
>>>> +if (GetBondedMaster() != this)
>>>> +#endif
>>>> + {
>>>> tone = SEC_TONE_OFF;
>>>> volt = SEC_VOLTAGE_13;
>>>> }
>>>>
>>
>> Can you please test whether this one works just as well?
>>
>> --- dvbdevice.c 2013/02/17 13:17:33 2.80
>> +++ dvbdevice.c 2013/02/19 10:18:08
>> @@ -742,7 +742,7 @@
>> if (const cDiseqc *diseqc = Diseqcs.Get(device->CardIndex() + 1,
>> channel.Source(), frequency, dtp.Polarization(), &scr)) {
>> frequency -= diseqc->Lof();
>> if (diseqc != lastDiseqc || diseqc->IsScr()) {
>> - if (GetBondedMaster() == this) {
>> + if (bondedMaster) {
>>ExecuteDiseqc(diseqc, &frequency);
>>if (frequency == 0)
>> return false;
>> @@ -768,7 +768,7 @@
>> tone = SEC_TONE_ON;
>> }
>
Re: [vdr] Device bonding
In article <51234507.6090...@tvdr.de> you write: >On 19.02.2013 01:48, Juergen Lock wrote: >> On Mon, Feb 18, 2013 at 11:52:31PM +0100, Klaus Schmidinger wrote: >>> On 18.02.2013 23:43, Juergen Lock wrote: >>>> In article <5121fba4.2050...@tvdr.de> you write: >>>>> On 16.02.2013 16:46, Juergen Lock wrote: >>>>>> Hi! >>>>>> >>>>>> Now that I have a spare DVB-S2 tuner (TechniSat SkyStar USB HD >>>>>> (adapter2); the others on this box are atm Hauppauge Nova-TD model >>>>>> 1172 (adapter 0+1) and TechnoTrend S2-3600 (adapter3) - all USB) I >>>>>> decided to play with vdr device bonding. I discovered three things: >>>>>> (still using vdr 1.7.29, I know I should upgrade... :) >>>>>> >>>>>> 1. The LNB setup OSD menu causes bonding to fail (it's trying to >>>>>> bond a DVB-T tuner) if I set the two DVB-S2 tuners as "connected >>>>>> to sat cable 1"; it works with "sat cable 2". Maybe it somehow >>>>>> thinks of (one of?) the DVB-T tuner(s) as cable 1 too? >>>>> >>>>> What does the "Setup/LNB" menu look like on your system? >>>>> Does it list only the two DVB-S devices, or all four of them? >>>>> Which device numbers does it display? >>>>> >>>>> What does the "DeviceBondings = ..." line in setup.conf look like >>>>> in both cases (working/not working)? >>>>> >>>> working: >>>> >>>> Einstellungen - LNB >>>> >>>> DiSEqC benutzen: nein >>>> SLOF (MHz): 11700 >>>> Untere LNB-Frequenz (MHz): 9750 >>>> Obere LNB-Frequenz (MHz): 10600 >>>> Device 3 angeschlossen an Sat-Kabel:2 >>>> Device 4 angeschlossen an Sat-Kabel:2 >>>> >>>> -> >>>> DeviceBondings = 1 0 2 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 >>>> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 >>>> >>>> broken: >>>> >>>> Einstellungen - LNB >>>> >>>> DiSEqC benutzen: nein >>>> SLOF (MHz): 11700 >>>> Untere LNB-Frequenz (MHz): 9750 >>>> Obere LNB-Frequenz (MHz): 10600 >>>> Device 3 angeschlossen an Sat-Kabel:1 >>>> Device 4 angeschlossen an Sat-Kabel:1 >>>> >>>> -> >>>> DeviceBondings = 1 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 >>>> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 >>>> >>>>> You wrote that your DVB-S2 device is "adapter2". Does this mean it >>>>> is actually "adaper2/frontend0" and "adapter2/frontend1"? >>>>> >>>>No the other DVB-S2 tuner is adapter3 (TechnoTrend S2-3600), all four >>>> only have frontend0 no frontend1. >>>> >>>>> Have you appliead any patches to VDR? >>>> >>>>Currently the two patches belonging to the iptv and ttxtsubs plugins >>>> and my stb0899 signal strength patch, and of course the FreeBSD >>>> portability patches. >>>> >>>>> If so, what happens without them? >>>> >>>>I will have to check that later tho I guess they are unrelated... >>>> >>>>> Same for plugins. >>>>> >>>>I just started vdr with just the xineliboutput plugin (I don't have >>>> an ff card) and got the same >>>> >>>> DeviceBondings = 1 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 >>>> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 >>>> >>>> when setting both DVB-S2 tuners as ".. connected to sat cable 1". >>>> >>>>I wonder, could this be a result of me running vdr with only the DVB-S2 >>>> tuners once and the first 1 in DeviceBondings that I may have set then >>>> simply doesn't get reset when the first two tuners became DVB-T? >>> >>> I'll have to further look into this, but you might be on to something here. >>> Please stop VDR, set that line to >>> >>> DeviceBondings = 0 0 2 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 >>> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 >>> >>> manually and restart VDR. Does it work then? >>> >> Yeah, looks like. (I should have tested that earlier... :) > >Just one more thing: did you get any log messages regarding device bonding >when it didn't work? > Sure, I just reproduced it: ERROR: can't bond device 3 with device 1 (only DVB-S(2) devices can be bonded) >> Btw did you take a look at the bondMutex vs mutex locking yet? I've had >> no further deadlocks with the second patch now. > >I was a little cnfused about this at first ;-) >Will look into it later. > >BTW: you sent your original posting "To" me and "Cc"d the VDR-ML. Therefore my >reply >inadvertently only went to you and not to the list. I'm no replying explicitly >to the >list. Please send postings only to the list and do not Cc me (unless you only >want to >contact me privately). > Oh, sorry, will try to remember. Thanx, Juergen ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Device bonding
In article <5123ead9.7050...@tvdr.de> you write:
>On 19.02.2013 21:32, Juergen Lock wrote:
>> In article <51235356.60...@tvdr.de> you write:
>>> On 19.02.2013 11:19, Klaus Schmidinger wrote:
>>>> On 18.02.2013 23:51, Juergen Lock wrote:
>>>>> On Sun, Feb 17, 2013 at 04:34:25PM +0100, Juergen Lock wrote:
>>>>>> On Sat, Feb 16, 2013 at 04:46:36PM +0100, Juergen Lock wrote:
>>>>>>> Hi!
>>>>>>>
>>>>>>> [...]
>>>>>>
>>>>>>> 3. Running with these four tuners (dual DVB-T and the bonded two DVB-S2)
>>>>>>> I get two different deadlocks waiting for cDvbTuner::bondMutex
>>>>>>> after live viewing a DVB-T(!) channel for longer (OSD doesn't
>>>>>>> react anymore and attaching gdb reveals two threads waiting for
>>>>>>> bondMutex) - the following two changes make it work but there
>>>>>>> probably is a better fix: (patch may apply with offsets; one
>>>>>>> of the problems I think is a lock order reversal with
>>>>>>> cDvbTuner::mutex
>>>>>>> and bondMutex when cDvbTuner::SetChannel calls back into itself
>>>>>>> with bondMutex held.)
>>>>>>>
>>>>>>> --- dvbdevice.c.orig
>>>>>>> +++ dvbdevice.c
>>>>>>> @@ -476,8 +476,10 @@ void cDvbTuner::SetChannel(const cChanne
>>>>>>> t->SetChannel(NULL);
>>>>>>> }
>>>>>>> }
>>>>>>> -else if (strcmp(GetBondingParams(Channel),
>>>>>>> BondedMaster->GetBondingParams()) != 0)
>>>>>>> +else if (strcmp(GetBondingParams(Channel),
>>>>>>> BondedMaster->GetBondingParams()) != 0) {
>>>>>>> + bondMutex.Unlock();
>>>>>>> BondedMaster->SetChannel(Channel);
>>>>>>> + }
>>>>>>>}
>>>>>>> cMutexLock MutexLock(&mutex);
>>>>>>> if (!IsTunedTo(Channel))
>>>>>>> @@ -761,7 +773,12 @@ bool cDvbTuner::SetFrontend(void)
>>>>>>> tone = SEC_TONE_ON;
>>>>>>> }
>>>>>>>int volt = (dtp.Polarization() == 'V' || dtp.Polarization()
>>>>>>> == 'R') ? SEC_VOLTAGE_13 : SEC_VOLTAGE_18;
>>>>>>> -if (GetBondedMaster() != this) {
>>>>>>> +#if 1
>>>>>>> +if (bondedTuner && !bondedMaster)
>>>>>>> +#else
>>>>>>> +if (GetBondedMaster() != this)
>>>>>>> +#endif
>>>>>>> + {
>>>>>>> tone = SEC_TONE_OFF;
>>>>>>> volt = SEC_VOLTAGE_13;
>>>>>>> }
>>>>>>>
>>>>>>
>>>>>> Hmm looks like I posted too soon, the first hunk is actually too much
>>>>>> and causes other deadlocks (like when trying to play a DVB-S channel
>>>>>> via streamdev while live viewing another), so the patch I'm not testing
>>>>>
>>>>> .. I'm _now_ testing...
>>>>>
>>>>>> becomes:
>>>>>>
>>>>>> --- dvbdevice.c.orig
>>>>>> +++ dvbdevice.c
>>>>>> @@ -761,7 +773,12 @@ bool cDvbTuner::SetFrontend(void)
>>>>>> tone = SEC_TONE_ON;
>>>>>> }
>>>>>>int volt = (dtp.Polarization() == 'V' || dtp.Polarization()
>>>>>> == 'R') ? SEC_VOLTAGE_13 : SEC_VOLTAGE_18;
>>>>>> -if (GetBondedMaster() != this) {
>>>>>> +#if 1
>>>>>> +if (bondedTuner && !bondedMaster)
>>>>>> +#else
>>>>>> +if (GetBondedMaster() != this)
>>>>>> +#endif
>>>>>> + {
>>>>>> tone = SEC_TONE_OFF;
>>>>>> volt = SEC_VOLTAGE_13;
>>>>>> }
>>>>>>
>>>>
>>>> Can you please test whether this one works
Re: [vdr] VDR 1.7 FreeBSD segfault when cutting recordings
In article <20130316082610.gj23...@t60.brauer.lan> you write:
>On Fri, Mar 15, 2013 at 10:54:04AM +0100, Gerhard Brauer wrote:
>>
>> I never have any problem during other actions with the remote VDR
>> (recording, viewing, place cutting marks,...) _exept_ when i start
>> the cutting procedere itself with the keyboard shortcut "2".
>> Most times (> 95%) the remote vdr segfaults immidiatly. The file
>> structure is still created (%foobar ff.). In the few times when it
>> not segfaults then the cutting is done well without problems.
>
>Hello again,
>
>I've learned that i could also start the cutting process on the vdr
>server itself, without a frontend. With this i also (and 100%
>reproducable) got the segfault of the vdr.
>
>I start without a running vdr:
>s01# vdr -u vdr
>--edit=/video/Die_Marx_Brothers_im_Kaufhaus/2012-10-29.01.48.50.99.rec/
>and also with a still running vdr and call the --edit with another instance:
>vdr -u vdr -i 1
>--edit=/video/Die_Marx_Brothers_im_Kaufhaus/2012-10-29.01.48.50.99.rec/
>
>From both tries i make backtraces with gdb, both differs only in
>thread numbering etc.
>So i attach the one with -i 1 instance, along with the vdr logfile
>output. Maybe one of you see a clearer picture why this segfaults
>happen here.
>
>I attach logfile sequence and backtrace output together.
>
>Regards and TIA
>
>Gerhard
>
>
>
>--M/SuVGWktc5uNpra
>Content-Type: text/plain; charset=us-ascii
>Content-Disposition: attachment; filename="log+backtrace.txt"
>Content-Transfer-Encoding: quoted-printable
>
>[Here i restarted the vdr on the server]
>
>Mar 16 08:30:09 s01 vdr: [50361344] VDR version 1.7.29 started
>Mar 16 08:30:09 s01 vdr: [50361344] switched to user 'vdr'
>Mar 16 08:30:09 s01 vdr: [50361344] running as daemon (tid=3D50361344)
>Mar 16 08:30:09 s01 vdr: [50361344] codeset is 'UTF-8' - known
>Mar 16 08:30:09 s01 vdr: [50361344] found 28 locales in /usr/local/share/lo=
>cale
>Mar 16 08:30:09 s01 vdr: [50361344] loading plugin: /usr/local/lib/vdr/libv=
>dr-xineliboutput.so.1.7.29
>Mar 16 08:30:09 s01 vdr: [50361344] loading /usr/local/etc/vdr/setup.conf
>Mar 16 08:30:09 s01 vdr: [50361344] loading /usr/local/etc/vdr/sources.conf
>Mar 16 08:30:09 s01 vdr: [50361344] loading /usr/local/etc/vdr/diseqc.conf
>Mar 16 08:30:09 s01 vdr: [50361344] loading /usr/local/etc/vdr/scr.conf
>Mar 16 08:30:09 s01 vdr: [50361344] loading /usr/local/etc/vdr/channels.conf
>Mar 16 08:30:09 s01 vdr: [50361344] loading /usr/local/etc/vdr/timers.conf
>Mar 16 08:30:09 s01 vdr: [50361344] loading /usr/local/etc/vdr/svdrphosts.c=
>onf
>Mar 16 08:30:09 s01 vdr: [50361344] loading /usr/local/etc/vdr/remote.conf
>Mar 16 08:30:09 s01 vdr: [50361344] loading /usr/local/etc/vdr/keymacros.co=
>nf
>Mar 16 08:30:09 s01 vdr: [50363392] video directory scanner thread started =
>(pid=3D15494, tid=3D50363392)
>Mar 16 08:30:09 s01 vdr: [50361344] registered source parameters for 'A - A=
>TSC'
>Mar 16 08:30:09 s01 vdr: [50365440] epg data reader thread started (pid=3D1=
>5494, tid=3D50365440)
>Mar 16 08:30:09 s01 vdr: [50364416] video directory scanner thread started =
>(pid=3D15494, tid=3D50364416)
>Mar 16 08:30:09 s01 vdr: [50361344] registered source parameters for 'C - D=
>VB-C'
>Mar 16 08:30:09 s01 vdr: [50361344] registered source parameters for 'S - D=
>VB-S'
>Mar 16 08:30:09 s01 vdr: [50361344] registered source parameters for 'T - D=
>VB-T'
>Mar 16 08:30:09 s01 vdr: [50361344] probing /dev/dvb/adapter0/frontend0
>Mar 16 08:30:09 s01 vdr: [50365440] reading EPG data from /video/epg.data
>Mar 16 08:30:09 s01 vdr: [50361344] creating cDvbDevice
>Mar 16 08:30:09 s01 vdr: [50361344] new device number 1
>Mar 16 08:30:09 s01 vdr: [50361344] frontend 0/0 provides DVB-T with QPSK,Q=
>AM16,QAM64 ("DiBcom 7000PC")
>Mar 16 08:30:09 s01 vdr: [50361344] found 1 DVB device
>Mar 16 08:30:09 s01 vdr: [50366464] tuner on frontend 0/0 thread started (p=
>id=3D15494, tid=3D50366464)
>Mar 16 08:30:09 s01 vdr: [50361344] initializing plugin: xineliboutput (1.0=
>=2E90-cvs): X11/xine-lib Ausgabe-Plugin
>Mar 16 08:30:09 s01 vdr: [50366464] cTimeMs: using monotonic clock (resolut=
>ion is 70 ns)
>Mar 16 08:30:09 s01 vdr: [50367488] section handler thread started (pid=3D1=
>5494, tid=3D50367488)
>Mar 16 08:30:09 s01 vdr: [50361344] new device number 64
>Mar 16 08:30:09 s01 vdr: [50361344] setting primary device to 2
>Mar 16 08:30:09 s01 vdr: [50364416] video directory scanner thread ended (p=
>id=3D15494, tid=3D50364416)
>Mar 16 08:30:10 s01 vdr: [50361344] assuming manual start of VDR
>Mar 16 08:30:10 s01 vdr: [50361344] SVDRP listening on port 6419
>Mar 16 08:30:10 s01 vdr: [50361344] setting current skin to "lcars"
>Mar 16 08:30:10 s01 vdr: [50361344] loading /usr/local/etc/vdr/themes/lcars=
>-default.theme
>Mar 16 08:30:10 s01 vdr: [50361344] starting plugin: xineliboutput
>Mar 16 08:30:10 s01 vdr: [50365440] epg data reader thread ended (pid=3D154=
>94, tid=3D50365440)
>Mar 16 08:30:10 s01 vdr: [50370560] Remote decoder/display server
Re: [vdr] VDR 1.7 FreeBSD segfault when cutting recordings
In article <514637fa.5080...@tvdr.de> you write:
>On 17.03.2013 21:52, Juergen Lock wrote:
>> ...
>> Ok I looked at cutter.c again and now I think I found the cause:
>> Linux must default to bigger thread stacks than FreeBSD, FreeBSD's
>> default seems to be 2 MB on amd64 and MAXFRAMESIZE is almost 1 MB...
>> Try the patch below, you can put it in files/patch-z-cutter.c
>> in the port dir. (the thread.c part is FreeBSD port specific, it
>> caused a different crash with --edit.)
>>
>> HTH, :)
>> Juergen
>>
>> --- cutter.c.orig
>> +++ cutter.c
>> @@ -83,7 +83,18 @@ void cCuttingThread::Action(void)
>>int LastIFrame = 0;
>>toMarks.Add(0);
>>toMarks.Save();
>> +#ifdef __FreeBSD__
>> + // XXX save thread stack space
>> + uchar *buffer = MALLOC(uchar, MAXFRAMESIZE);
>> + uchar *buffer2 = MALLOC(uchar, MAXFRAMESIZE);
>> + if (buffer == NULL || buffer2 == NULL) {
>> +free(buffer);
>> +error = "malloc";
>> +return;
>> +}
>> +#else
>>uchar buffer[MAXFRAMESIZE], buffer2[MAXFRAMESIZE];
>> +#endif
>>int Length2;
>>bool CheckForSeamlessStream = false;
>>bool LastMark = false;
>> @@ -216,6 +227,10 @@ void cCuttingThread::Action(void)
>> }
>> }
>>Recordings.TouchUpdate();
>> +#ifdef __FreeBSD__
>> + free(buffer);
>> + free(buffer2);
>> +#endif
>>}
>> else
>>esyslog("no editing marks found!");
>
>I assume this patch is against an older version of VDR, because in the
>current developer version this looks different. However, there are still
>places where two buffers with a size of MAXFRAMESIZE are allocated on the
>stack. So I guess I will change these to be allocated on the heap for
>version 2.0.
>
Ah yes, I'm still at 1.7.29, sorry I should have said...
Thanx! :)
Juergen
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR 1.7 FreeBSD segfault when cutting recordings
In article <5146cc8e.4070...@tvdr.de> you write:
>On 18.03.2013 08:41, Gerhard Brauer wrote:
>> On Sun, Mar 17, 2013 at 09:52:46PM +0100, Juergen Lock wrote:
>>>>
>>> Ok I looked at cutter.c again and now I think I found the cause:
>>> Linux must default to bigger thread stacks than FreeBSD, FreeBSD's
>>> default seems to be 2 MB on amd64 and MAXFRAMESIZE is almost 1 MB...
>>> Try the patch below, you can put it in files/patch-z-cutter.c
>>> in the port dir. (the thread.c part is FreeBSD port specific, it
>>> caused a different crash with --edit.)
>>
>> Hello!
>> Thanks for the patch and your time, i think we're on the way ;-)
>>
>> The cutting process now works without segfaulting or unbehavior exit
>> of the vdr process itself - but during cutting i got A LOT of "frame
>> larger than buffer" x greater then 8 (8 is fix in all messages).
>> ---
>> Mar 18 08:30:12 s01 vdr: [50364416] ERROR: frame larger than buffer (17392 >
>> 8)
>> Mar 18 08:30:12 s01 vdr: [50364416] ERROR: frame larger than buffer (17514 >
>> 8)
>> Mar 18 08:30:12 s01 vdr: [50364416] video cutting thread ended (pid=33513,
>> tid=50364416)
>> Mar 18 08:30:13 s01 vdr: [50361344] info: Schnitt beendet
>> ---
>> The cutting ends now always normally.
>>
>> The cutted recording itself seems to be corrupted. When trying to
>> play it i got "incomplete PES packet":
>> ---
>> Mar 18 08:23:05 s01 vdr: [54684672] receiver on device 1 thread ended
>> (pid=33513, tid=54684672)
>> Mar 18 08:23:05 s01 vdr: [50363392] ERROR: incomplete PES packet!
>> Mar 18 08:23:11 s01 last message repeated 87971 times
>> -
>> until i stop playing the cutted video.
>>
>> Same errors when doing it without a frontend/OSD from Terminal with
>> --edit and -i1.
>
>I guess the problem is that Juergen has allocated the buffers on the
>heap, but did not change the places where the buffer size is determined
>using sizeof(buffer) and sizeof(buffer2). If you replace these with
>MAXFRAMESIZE it should work.
>
Oh haha I'm sorry, how could I have missed that... I'll fix it tonight
and probably commit the working :) fix to ports.
Thanx!
Juergen
>Klaus
>
>>> --- cutter.c.orig
>>> +++ cutter.c
>>> @@ -83,7 +83,18 @@ void cCuttingThread::Action(void)
>>>int LastIFrame = 0;
>>>toMarks.Add(0);
>>>toMarks.Save();
>>> +#ifdef __FreeBSD__
>>> + // XXX save thread stack space
>>> + uchar *buffer = MALLOC(uchar, MAXFRAMESIZE);
>>> + uchar *buffer2 = MALLOC(uchar, MAXFRAMESIZE);
>>> + if (buffer == NULL || buffer2 == NULL) {
>>> +free(buffer);
>>> +error = "malloc";
>>> +return;
>>> +}
>>> +#else
>>>uchar buffer[MAXFRAMESIZE], buffer2[MAXFRAMESIZE];
>>> +#endif
>>>int Length2;
>>>bool CheckForSeamlessStream = false;
>>>bool LastMark = false;
>>> @@ -216,6 +227,10 @@ void cCuttingThread::Action(void)
>>> }
>>> }
>>>Recordings.TouchUpdate();
>>> +#ifdef __FreeBSD__
>>> + free(buffer);
>>> + free(buffer2);
>>> +#endif
>>>}
>>> else
>>>esyslog("no editing marks found!");
>>> --- thread.c.orig
>>> +++ thread.c
>>> @@ -242,7 +242,7 @@ void cThread::SetPriority(int Priority)
>>> void cThread::SetIOPriority(int Priority)
>>> {
>>> #ifdef __FreeBSD__
>>> - esyslog("ERROR: syscall(SYS_ioprio_set ...) unsupported on FreeBSD");
>>> + // esyslog("ERROR: syscall(SYS_ioprio_set ...) unsupported on FreeBSD");
>>> #else
>>> if (syscall(SYS_ioprio_set, 1, 0, (Priority & 0xff) | (2 << 13)) < 0)
>>> // best effort class
>>>LOG_ERROR;
>
>___
>vdr mailing list
>vdr@linuxtv.org
>http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] recording teletext (like for subtitles...)
Hi! As some of you might have seen when browsing my http://people.freebsd.org/~nox/dvb/ page and the threads I linked, I also have made a hack to make vdr 1.7.15 timers include teletext in the ts recordings, maybe this is useful as a first start to properly implement that feature. I'll just quote the relevant part from this posting: http://lists.freebsd.org/pipermail/freebsd-multimedia/2010-July/011158.html [...] - And something completely different: make vdr timers also record teletext; this came up on irc too and is mostly useful for subtitles transmitted that way - the osdteletext plugin doesnt seem to display them on playback but you can point e.g. vlc at the recorded .ts file below /video and click on the teletext icon in the bottom left - or use projectx to process subtitles including turning them into .sub files or just remux the .ts to make projectx add subtitle pagenumbers and correct(?) the teletext language because neither that nor the pmt pid are currently in the channels.conf so the patch just `guesses' by simply using the language of the first audio track. vlc at least doesn't seem to care much tho, it still displayed TV Polonia's teletext the same even when forcing the teletext language in the recorded pmt to german. And fwiw, osdteletext didn't want to display the teletext of neither TV Polonia nor of the french versions of arte (maybe because of different encoding?), and vlc pointed at TV Polonia via streamdev got a wrong teletext start page. (164 instead of 100, for some reason dvbsnoop -pd 9 -s ts -tssubdecode -if ... didn't want to decode the pmt of a streamdev recording from there...) http://people.freebsd.org/~nox/dvb/patch-vdr-1.7.15-record-teletext.txt [...] Cheers, Juergen ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] portability or VDR on FreeBSD
In article <20080311202112.i44...@unqrf.nqzva.sez2> you write: >-BEGIN PGP SIGNED MESSAGE- >Hash: SHA1 > > >On Fri, 7 Mar 2008, Joerg Pulz wrote: > >> Replying to myself. >> >> The next patches are ready, this time for the mp3/mplayer plugins and the >> dvd plugin. >> The patches can be found at ftp://ftp.frm2.tum.de/pub/jpulz/VDR/ . >> I've written a small README.FreeBSD as quickstart guide available at the >> above link too. >> I've not attached the patches to this mail to not pollute the list with >> stuff of lower interest for the bigger part of the VDR community. > >And again, replying to myself. > >The next round of patches is there. Available at the same place as >mentioned above. The README got an update too. >There is still full Linux compatibility, so the patched version of VDR and >the plugins can be compiled on a Linux box without any difference to the >unpatched version. > >As always, comments are welcome. Hi! (This is mostly for the list since Joerg already knows...) I meanwhile have ported a few more plugins and the live and vdradmin-am webinterfaces and am updating a preliminary shar that can be used to install all that the FreeBSD /usr/ports way. (tho there are still rough edges and the ports are not commit-ready yet.) See here: http://people.freebsd.org/~nox/dvb/ And yes you can now also use tuners on FreeBSD mainly thanx to webcamd: (I am using a PCTV 452e Sat HDTV Pro USB dvb-s2 one.) http://www.freshports.org/multimedia/webcamd Back to portability: I you look at the patches in the shar, http://people.freebsd.org/~nox/dvb/vdrdevel-preliminary.shar i.e. everything called */vdr*/files/patch-* in there (many are from Joerg but I meanwhile also added quite a few), I think at least those parts that touch C(++) sources and headers should be ready to be merged back upstream (Makefile patches maybe less so) - so maybe we should start submitting them back to the individual maintainers... Anyway, now you know. :) Cheers, Juergen ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] recording teletext (like for subtitles...)
In article you write: >On Sat, 10 Jul 2010, Juergen Lock wrote: > >> page and the threads I linked, I also have made a hack to make vdr >> 1.7.15 timers include teletext in the ts recordings, maybe this is >> useful as a first start to properly implement that feature. I'll > >You might like to have a look at my tpid patch that implements >subtitling page numbers and channels.conf support that are currently >missing in your patch: > >http://www.saunalahti.fi/~rahrenbe/vdr/patches/vdr-1.7.15-tpid.patch.gz > >The tpid patch is nowadays superceded by a patchset done under ttxtsubs >that was intended to be the basis of ttxtsubs implementation in core VDR >(patches 0001-0005): > >http://projects.vdr-developer.org/repositories/browse/plg-ttxtsubs/patches/patch-set.1.7.15 Ah that looks much better, thank you! :) Juergen ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.17
In article <4d7caea2.9050...@tvdr.de> you write: >VDR developer version 1.7.17 is now available at > > ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.17.tar.bz2 > >A 'diff' against the previous version is available at > > ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.16-1.7.17.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. > > >[...] >- Fixed detecting frames on channels that broadcast with 50 or 60 fps. > This avoids artifacts during fast forward/rewind when replaying recordings > from such > channels. To fix the index of existing recordings from such channels, just > delete the > 'index' file of the recording and VDR will generate a new one the next time > you play it. > You should also change the line "F 25" to "F 50" in the 'info' file of that > recording. >[...] I wonder if I'm chasing a ghost there... am I really the only one seeing this? I can't get this index rebuilding to work regardless if I try it with old or new recordings, if I mv away the original index file that was created with a recording I always get totally different index files rebuilt (checked with hexdump/cmp -l) that cause playbacks (via xineliboutput) to look quite corrupted immediately and make vdr-sxfe hang at eof too. This is vdr 1.7.17, xineliboutput is a 1.0.90s20110308.2305 checkout, FreeBSD 8.2/amd64, using these ports: http://people.freebsd.org/~nox/dvb/vdr-20110317a.shar (originally noticed with recordings from arte hd on 19.2E, but also reproduced with new short sd recordings, even from dvb-t.) ..and before I forget, Thanx for vdr! :) Juergen ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.17
In article <4d849b3a.6060...@tvdr.de> you write: >On 17.03.2011 22:36, Juergen Lock wrote: >> In article <4d7caea2.9050...@tvdr.de> you write: >>> VDR developer version 1.7.17 is now available at >>> >>> ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.17.tar.bz2 >>> >>> A 'diff' against the previous version is available at >>> >>> ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.16-1.7.17.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. >>> >>> >>> [...] >>> - Fixed detecting frames on channels that broadcast with 50 or 60 fps. >>> This avoids artifacts during fast forward/rewind when replaying recordings >>> from such >>> channels. To fix the index of existing recordings from such channels, just >>> delete the >>> 'index' file of the recording and VDR will generate a new one the next >>> time you play it. >>> You should also change the line "F 25" to "F 50" in the 'info' file of >>> that recording. >>> [...] >> >> I wonder if I'm chasing a ghost there... am I really the only one >> seeing this? I can't get this index rebuilding to work regardless >> if I try it with old or new recordings, if I mv away the original >> index file that was created with a recording I always get totally >> different index files rebuilt (checked with hexdump/cmp -l) that >> cause playbacks (via xineliboutput) to look quite corrupted immediately >> and make vdr-sxfe hang at eof too. >> >> This is vdr 1.7.17, xineliboutput is a 1.0.90s20110308.2305 checkout, >> FreeBSD 8.2/amd64, using these ports: >> >> http://people.freebsd.org/~nox/dvb/vdr-20110317a.shar >> >> (originally noticed with recordings from arte hd on 19.2E, but also >> reproduced with new short sd recordings, even from dvb-t.) > >I just made a recording from "arte HD" with VDR 1.7.17 and everything worked >fine. >It played correctly (on a TT-S2 6400 prototype), the current and total >times displayed by the progress display were correct and I was able to >place and move an editing mark with the picture getting updated just >fine. So it also works when you stop vdr, mv the recording's index file away and then let vdr regenerate it? Could this be an amd64/x86_64 issue? Thanx, Juergen ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.17
In article <201103191519.p2jfjkzw037...@triton8.kn-bremen.de> you write: >In article <4d849b3a.6060...@tvdr.de> you write: >>On 17.03.2011 22:36, Juergen Lock wrote: >>> In article <4d7caea2.9050...@tvdr.de> you write: >>>> VDR developer version 1.7.17 is now available at >>>> >>>> ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.17.tar.bz2 >>>> >>>> A 'diff' against the previous version is available at >>>> >>>> ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.16-1.7.17.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. >>>> >>>> >>>> [...] >>>> - Fixed detecting frames on channels that broadcast with 50 or 60 fps. >>>> This avoids artifacts during fast forward/rewind when replaying >>>> recordings from such >>>> channels. To fix the index of existing recordings from such channels, >>>> just delete the >>>> 'index' file of the recording and VDR will generate a new one the next >>>> time you play it. >>>> You should also change the line "F 25" to "F 50" in the 'info' file of >>>> that recording. >>>> [...] >>> >>> I wonder if I'm chasing a ghost there... am I really the only one >>> seeing this? I can't get this index rebuilding to work regardless >>> if I try it with old or new recordings, if I mv away the original >>> index file that was created with a recording I always get totally >>> different index files rebuilt (checked with hexdump/cmp -l) that >>> cause playbacks (via xineliboutput) to look quite corrupted immediately >>> and make vdr-sxfe hang at eof too. >>> >>> This is vdr 1.7.17, xineliboutput is a 1.0.90s20110308.2305 checkout, >>> FreeBSD 8.2/amd64, using these ports: >>> >>> http://people.freebsd.org/~nox/dvb/vdr-20110317a.shar >>> >>> (originally noticed with recordings from arte hd on 19.2E, but also >>> reproduced with new short sd recordings, even from dvb-t.) >> >>I just made a recording from "arte HD" with VDR 1.7.17 and everything worked >>fine. >>It played correctly (on a TT-S2 6400 prototype), the current and total >>times displayed by the progress display were correct and I was able to >>place and move an editing mark with the picture getting updated just >>fine. > >So it also works when you stop vdr, mv the recording's index >file away and then let vdr regenerate it? Could this be an >amd64/x86_64 issue? Found the problem: The FreeBSD patches disable USE_FADVISE in tools.c, and there was an #else clause missing when its not defined: --- tools.c.orig +++ tools.c @@ -1669,6 +1669,9 @@ ssize_t cUnbufferedFile::Read(void *Data } } lastpos = curpos; +#else + if (bytesRead > 0) +curpos += bytesRead; #endif return bytesRead; } There is one remaining bug tho: After playback of a short recording (sd in this case, 20s or so), vdr seems to kind of hang and I have to kill it... Can you reproduce that? Longer recordings are not affected. Thanx, :) Juergen ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.17
In article <4d84ee1d.8090...@gmx.de> you write: >Am 19.03.2011 18:40, schrieb Juergen Lock: >> There is one remaining bug tho: After playback of a short recording >> (sd in this case, 20s or so), vdr seems to kind of hang and I have >> to kill it... Can you reproduce that? Longer recordings are not >> affected. > >This is probably an old bug: For me, VDR has always been hanging at the >end of a recording, if that recording is shorter than one minute. Takes >10 or 20 seconds, then brings you back to live view again. Its not that >annoying, as recordings are usually longer, so I've never been going on >bug hunt for this. Ah yeah, that could well be it. I also found that sometimes playback of a short recording that was played before(?) doesn't start until you hit green... (black screen or `no signal', don't remember.) Anyway, you are right, short recordings are kinda rare in real life. :) Thanx, Juergen ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] dvb-s(2) NumProvidedSystems() vs reelchannelscan
Hi!
There seems to be a change in recent vdr versions regarding
NumProvidedSystems() which at least the reelchannelscan plugin
uses to tell apart a dvb-s2 tuner from a dvb-s one in a few places,
apparently it used to return 2 for a dvb-s2 tuner and now returns 3.
Is this intentional?
I patched reelchannelscan like below: (would need to check the
vdr version to be general of course, this was for 1.7.18; symptom
was a manual scan wrote out qam32 modulation into the channels.conf
instead of qpsk and of course vdr couldn't tune the new channel(s).)
Thanx!
Juergen
--- a/csmenu.c
+++ b/csmenu.c
@@ -243,7 +243,7 @@ void cMenuChannelscan::TunerDetection()
txtstream << tr("DVB-C - Cable") << " (" << tr("Tuner") << ' '
<< tuner + 1 << ')';
stp = CABLE;
} else if (device->ProvidesSource(cSource::stSat)) {
-if (device->NumProvidedSystems() == 2) {
+if (device->NumProvidedSystems() == 3) {
//if(TunerIsRotor(tuner))
// txtstream << tr("DVB-S2 - Rotor") << " (" <<
tr("Tuner") << ' ' << tuner + 1 << ')';
//else
--- a/scan.c
+++ b/scan.c
@@ -421,7 +421,7 @@ void cScan::ScanNitServices()
void cScan::ScanDVB_S(cTransponder * tp, cChannel * c)
{
//const time_t tt = time(NULL);
- int maxmods = device->NumProvidedSystems() == 2? 4 : 2;
+ int maxmods = device->NumProvidedSystems() == 3? 4 : 2;
// esyslog("%s cTransponder* tp = %x cChannel *c = %x",
__PRETTY_FUNCTION__);
esyslog("maxmods = %d",maxmods);
@@ -431,7 +431,7 @@ void cScan::ScanDVB_S(cTransponder * tp,
;
// skip HD Transonders on SD Tuner
-if ( !device->NumProvidedSystems() == 2 && static_cast < cSatTransponder *
>(tp)->System() == 1)
+if ( !device->NumProvidedSystems() == 3 && static_cast < cSatTransponder *
>(tp)->System() == 1)
return;
unsigned int nRadio = radioChannelNames.size();
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] dvb-s(2) NumProvidedSystems() vs reelchannelscan
On Sat, May 07, 2011 at 08:11:20PM +0200, Juergen Lock wrote:
> Hi!
>
> There seems to be a change in recent vdr versions regarding
> NumProvidedSystems() which at least the reelchannelscan plugin
> uses to tell apart a dvb-s2 tuner from a dvb-s one in a few places,
> apparently it used to return 2 for a dvb-s2 tuner and now returns 3.
> Is this intentional?
>
> I patched reelchannelscan like below: (would need to check the
> vdr version to be general of course, this was for 1.7.18; symptom
> was a manual scan wrote out qam32 modulation into the channels.conf
> instead of qpsk and of course vdr couldn't tune the new channel(s).)
>
> Thanx!
> Juergen
>
> --- a/csmenu.c
> +++ b/csmenu.c
> @@ -243,7 +243,7 @@ void cMenuChannelscan::TunerDetection()
> txtstream << tr("DVB-C - Cable") << " (" << tr("Tuner") << '
> ' << tuner + 1 << ')';
> stp = CABLE;
> } else if (device->ProvidesSource(cSource::stSat)) {
> -if (device->NumProvidedSystems() == 2) {
> +if (device->NumProvidedSystems() == 3) {
> //if(TunerIsRotor(tuner))
> // txtstream << tr("DVB-S2 - Rotor") << " (" <<
> tr("Tuner") << ' ' << tuner + 1 << ')';
> //else
> --- a/scan.c
> +++ b/scan.c
> @@ -421,7 +421,7 @@ void cScan::ScanNitServices()
> void cScan::ScanDVB_S(cTransponder * tp, cChannel * c)
> {
> //const time_t tt = time(NULL);
> - int maxmods = device->NumProvidedSystems() == 2? 4 : 2;
> + int maxmods = device->NumProvidedSystems() == 3? 4 : 2;
>
> // esyslog("%s cTransponder* tp = %x cChannel *c = %x",
> __PRETTY_FUNCTION__);
> esyslog("maxmods = %d",maxmods);
> @@ -431,7 +431,7 @@ void cScan::ScanDVB_S(cTransponder * tp,
> ;
>
> // skip HD Transonders on SD Tuner
> -if ( !device->NumProvidedSystems() == 2 && static_cast < cSatTransponder
> * >(tp)->System() == 1)
> +if ( !device->NumProvidedSystems() == 3 && static_cast < cSatTransponder
> * >(tp)->System() == 1)
> return;
>
>unsigned int nRadio = radioChannelNames.size();
Sorry for following up to myself, but I forgot to say this is the
0.6.1+beta1.7.15 reelchannelscan snapshot that yavdr uses, ported
to FreeBSD:
http://www.freshports.org/multimedia/vdr-plugin-reelchannelscan/
http://ppa.launchpad.net/yavdr/stable-vdr/ubuntu/pool/main/v/vdr-plugin-reelchannelscan/vdr-plugin-reelchannelscan_0.6.1+beta1.7.15.orig.tar.gz
..and you can see all the FreeBSD patches I applied here:
http://www.freebsd.org/cgi/cvsweb.cgi/ports/multimedia/vdr-plugin-reelchannelscan/files/
files/patch-scan.c also should be relevant on non-FreeBSD too:
--- a/scan.c
+++ b/scan.c
@@ -197,7 +197,7 @@ bool cScan::StartScanning(cScanParameter
#ifndef DEVICE_ATTRIBUTES
char buffer[265];
-snprintf(buffer, sizeof(buffer), "/dev/dvb/adapter%d/frontend0", cardnr);
+snprintf(buffer, sizeof(buffer), "/dev/dvb/adapter%d/frontend0",
cDevice::GetDevice(cardnr)->CardIndex());
fd_frontend = open(buffer, O_RDONLY | O_NONBLOCK);
if (fd_frontend <= 0) {
@@ -932,12 +932,12 @@ void cScan::Action()
char *strDate;
asprintf(&strDate,"%s", asctime(localtime(&tt)));
strDate[strlen(strDate)-1] = 0;
- fprintf(fp,"\n\n%s tp=%4d, %6d(%d) TV:%4d Radio:%4d in %3d
sec",strDate,i , frequency, !alreadyScanned, tvChannelNames.size()-ntv,
radioChannelNames.size()-nradio, (int)difftime(t_out,t_in) );
+ fprintf(fp,"\n\n%s tp=%4d, %6d(%d) TV:%4ld Radio:%4ld in %3d
sec",strDate,i , frequency, !alreadyScanned, tvChannelNames.size()-ntv,
radioChannelNames.size()-nradio, (int)difftime(t_out,t_in) );
fclose(fp);
fp = fopen("/tmp/tScan.log","a");
//fprintf(fp,"\n\n%s tp=%4d, %6d/%2d/%5d TV:%4d Radio:%4d in
%3dsec",strDate,i , frequency,(*tp)->Modulation(), (*tp)->Symbolrate(),
tvChannelNames.size()-ntv, radioChannelNames.size()-nradio,
(int)difftime(t_out,t_in) );
- fprintf(fp,"\n\ntp=%4d, %6d/%2d/%5d TV:%4d Radio:%4d in %3dsec
new:%3d",i , frequency,(*tp)->Modulation(), (*tp)->Symbolrate(),
tvChannelNames.size()-ntv, radioChannelNames.size()-nradio,
(int)difftime(t_out,t_in),tvChannelNames.size()-ntv+
radioChannelNames.size()-nradio );
+ fprintf(fp,"\n\ntp=%4d, %6d/%2d/%5d TV:%4ld Radio:%4ld in %3dsec
new:%3ld",i , frequency,(*tp)->Modulation(), (*tp)->Symbolrate(),
tvChannelNames.size()-ntv, radioChannelNames.size()-nradio,
(int)difftime(t_out,t_in),tvChannelNames.size()-ntv+
radioChannelNames.size()-nradio );
fclose(fp);
free(strDate);
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] dvb-s(2) NumProvidedSystems() vs reelchannelscan
In article <4dd7c61e.8060...@tvdr.de> you write: >On 05/07/11 20:11, Juergen Lock wrote: >> Hi! >> >> There seems to be a change in recent vdr versions regarding >> NumProvidedSystems() which at least the reelchannelscan plugin >> uses to tell apart a dvb-s2 tuner from a dvb-s one in a few places, >> apparently it used to return 2 for a dvb-s2 tuner and now returns 3. >> Is this intentional? > >Yes, it is. > >2010-06-06: Version 1.7.15 > >... >- The various modulation types are now taken into account when selecting a >device for > a recording or live viewing, so that devices that provide more capabilities > are > spared. > >This was done by incrementing numProvidedSystems in cDvbDevice::cDvbDevice() >for every additional modulation type it provides. > Ah I see. Curious, what is the third modulation used on dvb-s(2) in addition to qpsk and 8psk? >I'm afraid the result from NumProvidedSystems() is in no way suitable >for determining whether the device is DVB-S or DVB-S2. Ok so what would then be the recommended way? Wondering... :) Juergen ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.19
In article <4dfe76ac.9030...@gmx.de> you write: >Am 19.06.2011 22:57, schrieb Klaus Schmidinger: >> On 19.06.2011 12:41, Klaus Schmidinger wrote: >>> - Fixed detecting frames in case the Picture Start Code or Access Unit >>> Delimiter >>> extends over TS packet boundaries (reported by Johan Andersson). >> >> I'm afraid this change causes a short distortion in video and audio >> when VDR switches from one .ts file to the next during replay. >> I have yet to investigate and fix this, just wanted to warn people >> who make important recordings with this new version - which, of course, >> nobody should do, since it is a developer version ;-) > >Thanks for the hint, reverted to 1.7.18 for now. Or, of course, would >have if I were using a developer version, which nobody would do. ;) > >Can you provide a diff that reverts just that changeset so we can use >all the other goodies of 1.7.19 for now? Eh, could, if we would use >developer builds, of course. ;) I just tried this, does it make sense to just revert all of the changes to vdr-1.7.19/recorder.c, vdr-1.7.19/recording.c, and vdr-1.7.19/remux.[ch] ? If this works I might commit the FreeBSD port that way... Thanx! :) Juergen ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.19
On Mon, Jun 20, 2011 at 07:32:52PM +0200, Klaus Schmidinger wrote: > On 20.06.2011 18:48, Juergen Lock wrote: > > In article<4dfe76ac.9030...@gmx.de> you write: > >> Am 19.06.2011 22:57, schrieb Klaus Schmidinger: > >>> On 19.06.2011 12:41, Klaus Schmidinger wrote: > >>>> - Fixed detecting frames in case the Picture Start Code or Access Unit > >>>> Delimiter > >>>> extends over TS packet boundaries (reported by Johan Andersson). > >>> > >>> I'm afraid this change causes a short distortion in video and audio > >>> when VDR switches from one .ts file to the next during replay. > >>> I have yet to investigate and fix this, just wanted to warn people > >>> who make important recordings with this new version - which, of course, > >>> nobody should do, since it is a developer version ;-) > >> > >> Thanks for the hint, reverted to 1.7.18 for now. Or, of course, would > >> have if I were using a developer version, which nobody would do. ;) > >> > >> Can you provide a diff that reverts just that changeset so we can use > >> all the other goodies of 1.7.19 for now? Eh, could, if we would use > >> developer builds, of course. ;) > > > > I just tried this, does it make sense to just revert all of the > > changes to vdr-1.7.19/recorder.c, vdr-1.7.19/recording.c, and > > vdr-1.7.19/remux.[ch] ? If this works I might commit the FreeBSD > > port that way... > > Pretty much so. > You'll miss out on a few other fixes, too, but that's no big deal. Very good, thank you! :) Juergen ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.20
On Sat, Aug 20, 2011 at 12:16:01PM +0200, Klaus Schmidinger wrote: > On 19.08.2011 20:48, Udo Richter wrote: > > Am 16.08.2011 23:13, schrieb Klaus Schmidinger: > >> On 16.08.2011 19:56, Udo Richter wrote: > >>> Am 16.08.2011 18:57, schrieb Klaus Schmidinger: > - cSkins::Message() now blocks calls from background threads (thanks to > Michael Eiler for reporting a crash in such a scenario). > >>> > >>> Unfortunately, this will break the osdserver-plugin, that does call > >>> these directly from the network interface thread - though not without > >>> first locking the main thread in a safe state. > >>> > >>> I'll see if I can work around this, or if I can come up with some other > >>> solution. > >> > >> Actually cSkins::QueueMessage() is supposed to be used for issuing > >> messages from a background thread. > > > > Sure, however QueueMessage does not wait and does not return an user key > > press. > > That's by design ;-) > A background thread is not supposed to do this! > > > Osdserver exports all of the message functions, including > > QueueMessage. > > Well, I guess it shouldn't. > > > I'll probably solve this by a main thread callback, some other parts of > > OsdServer do this already. > > > > > > A solution / extension on VDR side would be to replace the 'main thread' > > concept with a 'big VDR lock': A global lock that the main thread > > releases just before sleeping, and re-locks after waking up. That way, > > any background thread could use that lock to trap the main thread > > safely, and use all of the not thread safe parts of VDR that previously > > were only safely available to the main thread. > > > > I think the kernel guys have a big lock they don't use any more, maybe > > we can get that one. ;) > > The kernel developers only recently got rid of this, and they had good > reasons to do so, I guess. I wouldn't want to do that in VDR. The general reason kernels get a big (or "giant") lock is when adding smp support (more than one cpu, i.e. more than one thread can be running at a time so suddenly there's need for locking in a lot more places.) The reason that big lock is removed later (actually pushed out to different individual locks) is only to improve smp performance (less time spent waiting on a single lock), which I guess an userland app like vdr would have less reason to worry about. Just thought I'd mention... :) Juergen ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Crash on first start without setup.conf
Hi!
(I'm still on 1.7.19 so forgive me if this already has been solved...)
I just got a report that starting vdr without setup.conf crashes in
isnumber(Setup.InitialChannel) called from main() so I came up with
this bandaid fix:
--- vdr.c.orig
+++ vdr.c
@@ -735,6 +735,8 @@ int main(int argc, char *argv[])
if (!cDevice::WaitForAllDevicesReady(DEVICEREADYTIMEOUT))
dsyslog("not all devices ready after %d seconds", DEVICEREADYTIMEOUT);
+ if (((const char *)Setup.InitialChannel) == NULL)
+ Setup.InitialChannel = "0";
if (isnumber(Setup.InitialChannel)) { // for compatibility with old
setup.conf files
if (cChannel *Channel = Channels.GetByNumber(atoi(Setup.InitialChannel)))
Setup.InitialChannel = Channel->GetChannelID().ToString();
Is that ok or should cSetup::cSetup(void) in config.c be changed,
it doesn't initialize InitialChannel, there only is a comment:
// InitialChannel is initialized by constructor
Thanx,
Juergen
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [PATCH] random vdr-sxfe xvdr+tcp:// restart failures
Hi!
I finally debugged this and found the read() looking for the initial
"DATA\r\n" was sometimes gobbling up too much, i.e. the start of
the first ts packet when the server was sending it fast enough which
caused the demuxer to be out of sync and interpreting parts of the
ts packet as header with a way too big data size, and that caused
vdr-sxfe to bail out.
This patch fixed it for me:
--- a/xine_input_vdr.c
+++ b/xine_input_vdr.c
@@ -5639,7 +5662,7 @@ static int connect_tcp_data_stream(vdr_i
LOGERR("Data stream write error (TCP)");
} else if( XIO_READY != io_select_rd(fd_data)) {
LOGERR("Data stream poll failed (TCP)");
- } else if((n=read(fd_data, tmpbuf, sizeof(tmpbuf))) <= 0) {
+ } else if((n=read(fd_data, tmpbuf, sizeof("DATA\r\n") - 1)) <= 0) {
LOGERR("Data stream read failed (TCP)");
} else if(n<6 || strncmp(tmpbuf, "DATA\r\n", 6)) {
tmpbuf[n] = 0;
(Tho one may want to replace the other occurences of "6" with
"sizeof("DATA\r\n") - 1" there too to make clear where they come
from.)
HTH, :)
Juergen
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Crash on first start without setup.conf
In article <4ee366f8.2030...@tvdr.de> you write:
>On 09.12.2011 19:15, Juergen Lock wrote:
>> Hi!
>>
>> (I'm still on 1.7.19 so forgive me if this already has been solved...)
>
>I forgive you ;-)
>
>Actually it has been fixed in version 1.7.20, with an additional
>fix in 1.7.21.
Thanx! :)
This is the patch I merged into FreeBSD ports for now until I get
around to updating to 1.7.22:
--- config.c.orig
+++ config.c
@@ -399,7 +399,7 @@ cSetup::cSetup(void)
CurrentChannel = -1;
CurrentVolume = MAXVOLUME;
CurrentDolby = 0;
- // InitialChannel is initialized by constructor
+ InitialChannel = "";
InitialVolume = -1;
ChannelsWrap = 0;
EmergencyExit = 1;
--- vdr.c.orig
+++ vdr.c
@@ -735,12 +723,14 @@ int main(int argc, char *argv[])
if (!cDevice::WaitForAllDevicesReady(DEVICEREADYTIMEOUT))
dsyslog("not all devices ready after %d seconds", DEVICEREADYTIMEOUT);
- if (isnumber(Setup.InitialChannel)) { // for compatibility with old
setup.conf files
- if (cChannel *Channel = Channels.GetByNumber(atoi(Setup.InitialChannel)))
-Setup.InitialChannel = Channel->GetChannelID().ToString();
+ if (*Setup.InitialChannel) {
+ if (isnumber(Setup.InitialChannel)) { // for compatibility with old
setup.conf files
+if (cChannel *Channel =
Channels.GetByNumber(atoi(Setup.InitialChannel)))
+ Setup.InitialChannel = Channel->GetChannelID().ToString();
+}
+ if (cChannel *Channel =
Channels.GetByChannelID(tChannelID::FromString(Setup.InitialChannel)))
+Setup.CurrentChannel = Channel->Number();
}
- if (cChannel *Channel =
Channels.GetByChannelID(tChannelID::FromString(Setup.InitialChannel)))
- Setup.CurrentChannel = Channel->Number();
if (Setup.InitialVolume >= 0)
Setup.CurrentVolume = Setup.InitialVolume;
Channels.SwitchTo(Setup.CurrentChannel);
That seems to fix the problem for me.
Cheers,
Juergen
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] cheap dvb-s usb2.0 card
In article <4f5e50a4.8010...@embl.de> you write: >Hi, Hi, sorry for the late reply... > >Can somebody point out at a resonably priced DVB-S (or DVB-S2) USB2.0 >card to use with VDR? > >I found this one: >http://www.buydvb.net/tbs5922-usb-dvbs2-tv-box_p41.html > >but it seems a bit expensive... I don't have experience with usb dvb-s tuners but I can report good success with this dvb-s2 one using the (now) Linux 3.2 v4l/dvb tree under FreeBSD using webcamd: http://engl.technotrend.eu/2779/TT-connect__S2-3600.html Previously on Linux it needed the s2-liplianin tree but apparently since kernel 3.2 the pctv452e.c driver it uses has finally reached mainline. I realize this one is not as cheap as you may be able to get an old dvb-s-only model, but for dvb-s2 it's a pretty good price I think, and the important thing is unlike some other usb tuners this one _works_ and isn't picky wrt the usb host or anything like that. :) (and the remote works too, and you can even use an universal remote with a pvr350 config using ir-keytable in case you need extra buttons for things like starting/stopping vdr-sxfe or xbmv-pvr, or for fullscreen toggle.) HTH, Juergen ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.27
In article <4f6f0570.7050...@tvdr.de> you write:
>VDR developer version 1.7.27 is now available at
>
> ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.27.tar.bz2
>
>A 'diff' against the previous version is available at
>
> ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.26-1.7.27.diff
>
>[...]
Hi!
While upgrading from 1.7.22 to 1.7.27 I noticed epg scans on a
single tuner (with xineliboutput in this case) no longer seem to
happen while that tuner is in live view mode, even trying to force
a scan via the osd or via "svdrpsend scan" no longer does anything.
Am I right this is because eitscan.c cEITScanner::Process does
...
if (!Device->Receiving()) {
...
and device.c cDevice::Receiving's bool arg no longer does anything
i.e. it no longer checks the attached receiver's priorities and thus
returns true even for devices only in live view mode?
And if yes, what would be the proper fix? :)
Thanx!
Juergen
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.27
On Sat, Apr 07, 2012 at 11:39:38AM +0200, Klaus Schmidinger wrote:
> On 06.04.2012 22:13, Juergen Lock wrote:
> > In article<4f6f0570.7050...@tvdr.de> you write:
> >> VDR developer version 1.7.27 is now available at
> >>
> >>ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.27.tar.bz2
> >>
> >> A 'diff' against the previous version is available at
> >>
> >>ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.26-1.7.27.diff
> >>
> >> [...]
> >
> > Hi!
> >
> > While upgrading from 1.7.22 to 1.7.27 I noticed epg scans on a
> > single tuner (with xineliboutput in this case) no longer seem to
> > happen while that tuner is in live view mode, even trying to force
> > a scan via the osd or via "svdrpsend scan" no longer does anything.
> >
> > Am I right this is because eitscan.c cEITScanner::Process does
> >
> > ...
> > if (!Device->Receiving()) {
> > ...
> >
> > and device.c cDevice::Receiving's bool arg no longer does anything
> > i.e. it no longer checks the attached receiver's priorities and thus
> > returns true even for devices only in live view mode?
> >
> > And if yes, what would be the proper fix? :)
>
> Please try changing
>
> if (!Device->Receiving()) {
>
> to
>
> if (Device->Priority() < 0) {
>
>
Yep, that fixes it, now "svdrpsend scan" works again.
Thanx! :)
Juergen
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [PATCH, RFC] STB0899 signal strength (pctv452e, others too?)
Hi!
(I guess the forums are not the best place to post this, hence
reposted here...)
By accident I stumbled across the special case for TT-budget S2-3200
(DVB-S/DVB-S2) in vdr's dvbdevice.c, and since both my tuners using
the pctv452e driver have the same issue (which are STB0899 too,
issue is the red/yellow/green bars in femon/osd didn't appear)
I added an OPTION to the FreeBSD port (STB0899_SIGNAL in the port's
make config menu) to enable the patch below. Optional since I don't
know if there are STB0899-based tuners that don't have the problem,
does anyone here know? (see log, if vdr logs like
vdr: [29376960] frontend 0/0 provides DVB-S,DVB-S2,DSS with QPSK
("STB0899 Multistandard")
and the bars appear without the patch please let us know, noting
pci ids for the cards especially if different from 0x13c2:0x1019
or if it's usb, thanx!)
Cheers,
Juergen
And here comes the patch, also at:
http://www.freebsd.org/cgi/cvsweb.cgi/ports/multimedia/vdr/files/stb0899-signalstrength.patch?rev=1.2;content-type=text%2Fplain
--- dvbdevice.c.orig
+++ dvbdevice.c
@@ -560,6 +560,12 @@ int cDvbTuner::GetSignalStrength(void) c
switch (subsystemId) {
case 0x13C21019: MaxSignal = 670; break; // TT-budget S2-3200
(DVB-S/DVB-S2)
}
+#if 1
+ // XXX This is likely not correct for all cards using stb0899
+ // but pctv452e usb ones seem to be affected too...
+ if (!strcmp(device->DeviceName(), "STB0899 Multistandard"))
+MaxSignal = 670;
+#endif
int s = int(Signal) * 100 / MaxSignal;
if (s > 100)
s = 100;
@@ -632,6 +638,12 @@ int cDvbTuner::GetSignalQuality(void) co
switch (subsystemId) {
case 0x13C21019: MaxSnr = 200; break; // TT-budget S2-3200
(DVB-S/DVB-S2)
}
+#if 1
+ // XXX This is likely not correct for all cards using stb0899
+ // but pctv452e usb ones seem to be affected too...
+ if (!strcmp(device->DeviceName(), "STB0899 Multistandard"))
+ MaxSnr = 200;
+#endif
int a = int(Snr) * 100 / MaxSnr;
int b = 100 - (Unc * 10 + (Ber / 256) * 5);
if (b < 0)
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH, RFC] STB0899 signal strength (pctv452e, others too?)
On Sat, May 19, 2012 at 11:57:35PM +0200, Klaus Schmidinger wrote:
> On 19.05.2012 22:32, Juergen Lock wrote:
> > Hi!
> >
> > (I guess the forums are not the best place to post this, hence
> > reposted here...)
> >
> > By accident I stumbled across the special case for TT-budget S2-3200
> > (DVB-S/DVB-S2) in vdr's dvbdevice.c, and since both my tuners using
> > the pctv452e driver have the same issue (which are STB0899 too,
> > issue is the red/yellow/green bars in femon/osd didn't appear)
> > I added an OPTION to the FreeBSD port (STB0899_SIGNAL in the port's
> > make config menu) to enable the patch below. Optional since I don't
> > know if there are STB0899-based tuners that don't have the problem,
> > does anyone here know? (see log, if vdr logs like
> >
> > vdr: [29376960] frontend 0/0 provides DVB-S,DVB-S2,DSS with QPSK
> > ("STB0899 Multistandard")
> >
> > and the bars appear without the patch please let us know, noting
> > pci ids for the cards especially if different from 0x13c2:0x1019
> > or if it's usb, thanx!)
> >
> > Cheers,
> > Juergen
> >
> > And here comes the patch, also at:
> >
> >
> > http://www.freebsd.org/cgi/cvsweb.cgi/ports/multimedia/vdr/files/stb0899-signalstrength.patch?rev=1.2;content-type=text%2Fplain
> >
> > --- dvbdevice.c.orig
> > +++ dvbdevice.c
> > @@ -560,6 +560,12 @@ int cDvbTuner::GetSignalStrength(void) c
> > switch (subsystemId) {
> > case 0x13C21019: MaxSignal = 670; break; // TT-budget S2-3200
> > (DVB-S/DVB-S2)
> > }
> > +#if 1
> > + // XXX This is likely not correct for all cards using stb0899
> > + // but pctv452e usb ones seem to be affected too...
> > + if (!strcmp(device->DeviceName(), "STB0899 Multistandard"))
> > +MaxSignal = 670;
> > +#endif
> > int s = int(Signal) * 100 / MaxSignal;
> > if (s> 100)
> >s = 100;
> > @@ -632,6 +638,12 @@ int cDvbTuner::GetSignalQuality(void) co
> >switch (subsystemId) {
> > case 0x13C21019: MaxSnr = 200; break; // TT-budget S2-3200
> > (DVB-S/DVB-S2)
> > }
> > +#if 1
> > + // XXX This is likely not correct for all cards using stb0899
> > + // but pctv452e usb ones seem to be affected too...
> > + if (!strcmp(device->DeviceName(), "STB0899 Multistandard"))
> > + MaxSnr = 200;
> > +#endif
> >int a = int(Snr) * 100 / MaxSnr;
> >int b = 100 - (Unc * 10 + (Ber / 256) * 5);
> >if (b< 0)
>
> Maybe I'm missing something here, but why don't you just add the subsystem id
> of your card
> to the switch statements?
Heh.
Because a) it's usb, b) I'm on FreeBSD which doesn't emulate Linux'
/sys/class/dvb nodes and finding out which /dev/dvb node belongs
to which usbid isn't as straightforward there, and c) I was wondering
if the bug maybe affects all STB0899 frontends not just some.
Cheers,
Juergen
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Bad choices of USB cards
In article <5f5o89-7n7@wuwek.kopernik.gliwice.pl> you write: >Hello Hi! >I use VDR a few years, but lately I changed my system into ITX (AMD >Brazos) and so changed PCI DVB-S2 card into USB. Additionaly I has >bought DVB-T tuner. >While buying hardware I was sure I buy hardware which is supported >in-kernel, so no need to hunt for driver. >Unfortunatelly every from three card I have doesn't work properly. > >The first: Terratec Cinergy S2 USB HD. >Kernel has drivers, but only for the first revision. Second revision >which I have need a patch. Patch is even on linux-media >http://patchwork.linuxtv.org/patch/10294/ , but isn't finished so no >hope to have it in kernel soon. >Anyway I have applied it's modified version from >http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=653026 to kernel 3.2 >and it's almost work. Almost, because sometimes recording becames >unplayable. Recording recors eveything, but I can play only some part of >file from beginning. The rest is unplayable. > >Looking for something widely used I choosed Pinnacle PCTV SAT HDTV 452E >PRO USB. Problems with it i've described in thread: "[PATCH, RFC] >STB0899 signal strength (pctv452e, others too?)" > I have been using this card on FreeBSD as well as its `cousin' TT S2-3600 which uses the same driver with various versions of webcamd which used various versions of the Linux v4l/dvb tree (media_tree), first with bits from s2-liplianin merged in and since (I think) 3.2 using the pctv452e.c driver that was committed to the vanilla media_tree, and rarely ever had issues. Currently I'm using webcamd 3.5.0.2 which uses a snapshot of the for_3.5 branch of media_tree... http://www.freshports.org/multimedia/webcamd http://git.linuxtv.org/media_tree.git/shortlog/aa6d5f29534a6d1459f9768c591a7a72aadc5941 >The last miss was buying USB DVB-T stick based on Af9015. Generally it >works, but only a few minutes. I suspect it overheats... > >So I ask: if somebody has one of cards above working, please give me a >note with which kernel and with which driver it does work. > >Also I wold welcome advice, which from those rather cheap USB cards >works without any problems on stock linux kernel. I have been testing various other usb tuners (mainly dvb-t) on FreeBSD with webcamd (which as mentioned above uses linux' media_tree), see my (nox) entries on this page on the FreeBSD wiki: http://wiki.freebsd.org/WebcamCompat Besides the pctv452e/TT S2-3600 dvb-s2 tuners which _I_ had not many issues with I successfully tested the following dvb-t tuners using dib0700 hardware: PCTV NanoStick 73e SE (solo)[single tuner] Hauppauge Nova-TD model 1172[dual tuner] The Sony PlayTV which was mentioned later in this thread seems to use dib0700 hardware too, but at least here it seems to be much more expensive than the Nova-TD. (And the two af9015 tuners I tested didn't overheat but used to hang themselves up needing a temporary unplug when left running on vdr for a day or less, this _seems_ to be better with recent media_tree versions but I still had to restart at least vdr when it happened. You can reduce the probability for this to happen with vdr tho: change the osd setting "Setup -> DVB -> Update channels" to "names and PIDs" or lower.) HTH, Juergen ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
