[kaffeine] [Bug 381828] quick channel zapping eventually stops tv playback

2017-07-26 Thread Mauro Carvalho Chehab
https://bugs.kde.org/show_bug.cgi?id=381828

Mauro Carvalho Chehab  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #5 from Mauro Carvalho Chehab  ---
(In reply to Tuxo from comment #4)
> Hello Mauro, turns out it's my DVB-T usb Dongle, a "DigitalRise DVB-T USB
> 2.0 Ter Beetle " - this one still has some unfixed issues in kernel 4.9 (the
> kernel debian/stable uses). 

Kernel 4.9 had an important change, meant to improve security that badly
affected USB drivers. Yet, if the device is tuning, the required bug fixes
should already have been backported. The vp7045 driver is really simple: all it
does is to send commands to the device's internal firmware, with is responsible
internally to talk with the frontend. So, it is up to the firmware to tune.

So, what I suspect is that just increasing the timeout should be enough to make
it work with such device.

> It seems to affect the quick tuning. I'm testing
> now with a Hauppauge WinTV HVR-900H dongle and the issues are all gone.

OK, that confirms that this isn't a Kaffeine issue.

> Switching off vdpau with VDPAU_DRIVER=none is a good idea anyway, my older
> asrock mainboard can't deinterlace mpeg-2 in hardware, it has to happen in
> software. Increasing the tuning timeout to 4500ms (3x) for the Beetle device
> did not help.

Well, from its driver, it internally uses a Zarlink MT352 tuner, with is a very
old frontend. Perhaps it doesn't lock well on channels with higher throughput,
or perhaps the hardware is showing its age ;)

> 
> Please close this ticket, the problem is hardware related ...

OK, thanks for checking.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kaffeine] [Bug 381828] quick channel zapping eventually stops tv playback

2017-07-26 Thread Tuxo
https://bugs.kde.org/show_bug.cgi?id=381828

--- Comment #4 from Tuxo  ---
Hello Mauro, turns out it's my DVB-T usb Dongle, a "DigitalRise DVB-T USB 2.0
Ter Beetle " - this one still has some unfixed issues in kernel 4.9 (the kernel
debian/stable uses). It seems to affect the quick tuning. I'm testing now with
a Hauppauge WinTV HVR-900H dongle and the issues are all gone.

Switching off vdpau with VDPAU_DRIVER=none is a good idea anyway, my older
asrock mainboard can't deinterlace mpeg-2 in hardware, it has to happen in
software. Increasing the tuning timeout to 4500ms (3x) for the Beetle device
did not help.

Please close this ticket, the problem is hardware related ...

-- 
You are receiving this mail because:
You are watching all bug changes.

[kaffeine] [Bug 381828] quick channel zapping eventually stops tv playback

2017-07-26 Thread Mauro Carvalho Chehab
https://bugs.kde.org/show_bug.cgi?id=381828

--- Comment #3 from Mauro Carvalho Chehab  ---
(In reply to Tuxo from comment #2)
> Hello, sorry for the delay - I did not get a notification mail for your
> request, hope I fixed this now in my email preferences ...
> 
> I just build 2.0.12 from git and I'm afraid it still happens. Try switching
> with the previous/next buttons ... it will work for a wille then actually
> stop the playback. It's a clean stop with not errors: I just noticed even
> the play button changes from "play" to "stop" icon, but I'm not asking it to
> do so! 

Hmm.. perhaps for some reason the channel it tried to play was not detected.

If this is the case, if you enable DVB debug, you'll be able to see the
messages reporting it from:

   qCDebug(logDvb, "tuning failed on %.2f MHz", backend->getFrqMHz());

If that's the case, there's not much we can do at Kaffeine, as this is the
expected behavior: if a channel can't be played, it should be placed into STOP
mode. Yet, in such case, why the tuning is failing? It could be either due to:

1) The hardware takes a long time to tune, and Kaffeine gives up too early;
2) signal is too weak for some channels;
3) some Kernel driver or hardware issue.

For (1), there's a setting at the TV config screen that allows you to adjust
the maximum amount of time, in ms, that Kaffeine will wait for the driver to
lock into a channel. Kaffeine's default is 1500 ms. Such timeout depends on the
hardware. Changing it to a higher value should solve it.

For (2), you may need a better antenna.

At 2.0.12, you can enable dvb debug by calling Kaffeine with:

   QT_LOGGING_RULES=kaffeine.dvb.debug=true kaffeine

> Hitting "play" again will resume playback without an error. Weird
> stuff, could it be vdpau related? Can you tell me how to use the xvideo
> output instead of vdpau display output?

Take a look at README.md. It contains some instructions about how to adjust the
video output driver at libVLC.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kaffeine] [Bug 381828] quick channel zapping eventually stops tv playback

2017-07-26 Thread Tuxo
https://bugs.kde.org/show_bug.cgi?id=381828

--- Comment #2 from Tuxo  ---
Hello, sorry for the delay - I did not get a notification mail for your
request, hope I fixed this now in my email preferences ...

I just build 2.0.12 from git and I'm afraid it still happens. Try switching
with the previous/next buttons ... it will work for a wille then actually stop
the playback. It's a clean stop with not errors: I just noticed even the play
button changes from "play" to "stop" icon, but I'm not asking it to do so!
Hitting "play" again will resume playback without an error. Weird stuff, could
it be vdpau related? Can you tell me how to use the xvideo output instead of
vdpau display output?

-- 
You are receiving this mail because:
You are watching all bug changes.

[kaffeine] [Bug 381828] quick channel zapping eventually stops tv playback

2017-07-09 Thread Mauro Carvalho Chehab
https://bugs.kde.org/show_bug.cgi?id=381828

--- Comment #1 from Mauro Carvalho Chehab  ---
(In reply to Tuxo from comment #0)
> it works for a few channels, then it forces you to hit the playback button
> again to watch the channel you're on at the moment.

Could you please try with the -git version and see if the bug is still
reproductible?

-- 
You are receiving this mail because:
You are watching all bug changes.