Re: [vdr] Trouble with DVB-T2 on frontend 1

[Marko Mäkelä]

On Sun, Nov 26, 2017 at 07:21:58PM +0200, Marko Mäkelä wrote:

Hi all,

I recently got a USB adapter "Astrometa DVB-T2" that I would like to 
use with VDR. It comprises two frontends:


/dev/dvb/adapter0/frontend0: Realtek RTL2832 (DVB-T)
/dev/dvb/adapter0/frontend1: Panasonic MN88473 (DVB-T2 and DVB-C)


Apart from these files, in /dev/dvb/adapter0 I can see the following:
demux0 dvr0 net0

It seems to me that the dvbdevice.c of VDR 2.3.8 assumes that all these 
files exist for all frontends. But there is no demux1, dvr1, or net1 on 
my system.


In dvbdevice.h, I think that the macros DEV_VIDEO, DEV_DVB_VIDEO, 
DEV_DVB_AUDIO are unused and the definitions could be removed.


For cDvbTuner::SetFrontend() the cDvbTuner::adapter and 
cDvbTuner::frontend are already fixed. For my device, frontend0 should 
only be valid for DVB-T, while frontend1 is valid for DVB-T2 and DVB-C.  
How to handle these known-invalid combinations? By 'return true'?  Or 
should I rather hack cDvbTuner so that it opens a file descriptor for 
each frontend, and then chooses the appropriate one in 
cDvbTuner::SetFrontend() based on frontendType?


Last, I noticed that there exists cDvbDevice::BondDevices() for bonding 
multiple DVB-S devices to the same dish. I guess it is not feasible to 
extend this to my DVB-T/DVB-T2 device, because I would suppose that 
unlike the DVB-S devices, my USB stick does not support concurrent 
reception from both frontends at the same time.


Marko

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] VDR locking up

[VDR User]

>> I made this change few hours ago, but I'm still waiting for the
>> problem to appear.. Obviously it now is working 100%. :)

Same here.

> Does "working 100%" mean that youre not getting any of these error
> messages any more? Not even once?

I'm not getting them right now either but it only means the conditions
that cause it haven't occurred yet. It will though - it always does
sooner or later unfortunately.

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] VDR locking up

[Teemu Suikki]

yes, that's exactly what it means. :) Just bad (or good!) luck.
Yesterday it got stuck three times during the day.

The weather is better today. I think the error is caused by weak signal..


2017-11-27 12:04 GMT+02:00 Klaus Schmidinger :
> On 27.11.2017 09:04, Teemu Suikki wrote:
>>
>>
>> I made this change few hours ago, but I'm still waiting for the
>> problem to appear.. Obviously it now is working 100%. :)
>
>
> Does "working 100%" mean that youre not getting any of these error
> messages any more? Not even once?
>
> Klaus
>
>
>> 2017-11-27 0:08 GMT+02:00 Klaus Schmidinger :
>>>
>>> On 26.11.2017 19:09, Teemu Suikki wrote:


 I know I'm replying to a year old thread, but I'm having the exact same
 problem.

 I upgraded my system from kernel 3.16.0 to 4.4.0, and also TBS dvb
 drivers to latest version.. Now I have this problem, that randomly VDR
 starts flooding this "ERROR: TS packet not accepted in Transfer Mode"
 log. It will not jam right away, but after maybe 30-60min it is
 jammed.

 Some VDR functions like timers seem to still work, but the GUI is stuck.

 This is VDR 2.2.0 from yavdr repos.

 Any ideas?

 Even though this might be a driver bug, perhaps vdr of softhddevice
 could simply stop displaying the channel after the first error?
>>>
>>>
>>>
>>> I can't contribute anything regarding the driver or softhddevice,
>>> but I guess limiting the log message to, say, one message per minute
>>> could save the program from getting stuck.
>>> That's assuming your log is actually flooded with thousands of
>>> entries like that.
>>> To qickly verify this could you please precede the line
>>>
>>>   esyslog("ERROR: TS packet not accepted in Transfer Mode");
>>>
>>> in transfer.c with
>>>
>>>   static int Counter = 0;
>>>   if ((Counter++ % 1) == 0)
>>>
>>> Klaus
>
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr



-- 
Teemu Suikki
http://www.z-power.fi/

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] VDR locking up

[Klaus Schmidinger]

On 27.11.2017 09:04, Teemu Suikki wrote:


I made this change few hours ago, but I'm still waiting for the
problem to appear.. Obviously it now is working 100%. :)


Does "working 100%" mean that youre not getting any of these error
messages any more? Not even once?

Klaus


2017-11-27 0:08 GMT+02:00 Klaus Schmidinger :

On 26.11.2017 19:09, Teemu Suikki wrote:


I know I'm replying to a year old thread, but I'm having the exact same
problem.

I upgraded my system from kernel 3.16.0 to 4.4.0, and also TBS dvb
drivers to latest version.. Now I have this problem, that randomly VDR
starts flooding this "ERROR: TS packet not accepted in Transfer Mode"
log. It will not jam right away, but after maybe 30-60min it is
jammed.

Some VDR functions like timers seem to still work, but the GUI is stuck.

This is VDR 2.2.0 from yavdr repos.

Any ideas?

Even though this might be a driver bug, perhaps vdr of softhddevice
could simply stop displaying the channel after the first error?



I can't contribute anything regarding the driver or softhddevice,
but I guess limiting the log message to, say, one message per minute
could save the program from getting stuck.
That's assuming your log is actually flooded with thousands of
entries like that.
To qickly verify this could you please precede the line

  esyslog("ERROR: TS packet not accepted in Transfer Mode");

in transfer.c with

  static int Counter = 0;
  if ((Counter++ % 1) == 0)

Klaus


___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] VDR locking up

[Teemu Suikki]

Thanks!

I made this change few hours ago, but I'm still waiting for the
problem to appear.. Obviously it now is working 100%. :)

I now also got the open source TBS drivers to build properly, if they
work nicely I might switch over. Perhaps it fixes this too.


2017-11-27 0:08 GMT+02:00 Klaus Schmidinger :
> On 26.11.2017 19:09, Teemu Suikki wrote:
>>
>> I know I'm replying to a year old thread, but I'm having the exact same
>> problem.
>>
>> I upgraded my system from kernel 3.16.0 to 4.4.0, and also TBS dvb
>> drivers to latest version.. Now I have this problem, that randomly VDR
>> starts flooding this "ERROR: TS packet not accepted in Transfer Mode"
>> log. It will not jam right away, but after maybe 30-60min it is
>> jammed.
>>
>> Some VDR functions like timers seem to still work, but the GUI is stuck.
>>
>> This is VDR 2.2.0 from yavdr repos.
>>
>> Any ideas?
>>
>> Even though this might be a driver bug, perhaps vdr of softhddevice
>> could simply stop displaying the channel after the first error?
>
>
> I can't contribute anything regarding the driver or softhddevice,
> but I guess limiting the log message to, say, one message per minute
> could save the program from getting stuck.
> That's assuming your log is actually flooded with thousands of
> entries like that.
> To qickly verify this could you please precede the line
>
>   esyslog("ERROR: TS packet not accepted in Transfer Mode");
>
> in transfer.c with
>
>   static int Counter = 0;
>   if ((Counter++ % 1) == 0)
>
> Klaus
>
>
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr



-- 
Teemu Suikki
http://www.z-power.fi/

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr