Modify
Warning Please read the Ticket HowTo before creating or commenting on a ticket. Failure to do so may cause your ticket to be rejected or result in a slower response.

Opened 3 years ago

Closed 2 years ago

Last modified 2 years ago

#9830 closed Bug Report - General (Fixed)

error changing channel on PVR350

Reported by: Simon Kenyon <simon@…> Owned by: danielk
Priority: blocker Milestone: 0.25
Component: MythTV - General Version: Master Head
Severity: medium Keywords:
Cc: Ticket locked: no

Description

if i change channel then i get an black screen and return to the menu.
if i change to a channel on another card (in this case a DVB-S card) and when that works, change to a different channel on the pvr350, that also works.

so it is only changing from one channel to another on the pvr350 that does not work.

i attach a log from the backend made with important,general,playback

should i add additional flags to catch more log entries?

this is with:

ythTV Version : v0.25pre-1978-g4048e75
MythTV Branch : master
Network Protocol : 65
Library API : 0.25.20110522-1
QT Version : 4.6.3
Options compiled in:

linux debug use_hidesyms using_alsa using_jack using_oss using_backend using_bindings_perl using_bindings_python using_bindings_php using_dvb using_firewire using_frontend using_hdhomerun using_hdpvr using_iptv using_ivtv using_libxml2 using_libudf using_lirc using_mheg using_opengl_video using_qtdbus using_qtwebkit using_v4l2 using_v4l1 using_x11 using_xrandr using_xv using_bindings_perl using_bindings_python using_bindings_php using_mythtranscode using_opengl using_vdpau using_ffmpeg_threads using_live using_mheg using_libass using_libxml2 using_libudf

Attachments (5)

backend.log (7.3 KB) - added by Simon Kenyon <simon@…> 3 years ago.
log from mythbackend created with -v important,general,playback
mythbackend.log (53.5 KB) - added by Simon Kenyon <simon@…> 2 years ago.
mythbackendlog.txt (232.1 KB) - added by Bob K Mertz <online@…> 2 years ago.
mythbackend log
jumperror.log (61.7 KB) - added by Bob K Mertz <online@…> 2 years ago.
9830-debug-v1.patch (766 bytes) - added by danielk 2 years ago.

Download all attachments as: .zip

Change History (29)

Changed 3 years ago by Simon Kenyon <simon@…>

log from mythbackend created with -v important,general,playback

comment:1 Changed 3 years ago by mythtv@…

I think I am understating if I say that this problem is related to Ticket #9846. I would rather think this problem is a side-effect of Ticket #9846, and therefore this ticket should be voided.

comment:2 Changed 3 years ago by lapion <mythtv@…>

voided, or merged ?

comment:3 Changed 3 years ago by Simon Kenyon <simon@…>

maybe
neither ticket has been looked at

comment:4 Changed 3 years ago by beirdo

I'm not sure that this can be considered a duplicate, but I've cross-linked it.

Changed 2 years ago by Simon Kenyon <simon@…>

comment:5 Changed 2 years ago by Simon Kenyon <simon@…>

i updated my systems (brought them all up to date, built latest trunk)

i still have the issue, so i am attaching a new log from the backend (with important,record)

i had to chop a chunk of repeating entries from the log so i could post it

MythTV Version : v0.25pre-3777-g10273b5

MythTV Branch : master

Network Protocol : 69

Library API : 0.25.20111116-1

QT Version : 4.7.2

Options compiled in:

linux debug use_hidesyms using_alsa using_oss using_backend using_bindings_python using_bindings_php using_dvb using_firewire using_frontend using_hdhomerun using_hdpvr using_iptv using_ivtv using_libxml2 using_libudf using_lirc using_mheg
using_opengl_video using_qtwebkit using_qtscript using_qtdbus using_v4l2 using_x11 using_xrandr using_xv using_bindings_python using_bindings_php using_mythtranscode using_opengl using_vdpau using_ffmpeg_threads using_live using_mheg using_libass using_libxml2 using_libudf

comment:6 Changed 2 years ago by Bob K Mertz <online@…>

This issue is also affecting me since upgrading to 0.25 on a Mythbuntu 11.10 system. On my system I am using a total of 3 PVR-150 tuner cards with 2 being connected to analog cable and 1 being connected to a Dish Network receiver. Everything functioned perfectly on 0.24 (I was not running 0.24 fixes) but now everything works but I exhibit the same results with not being able to change channels directly from one dish network channel to another (ie. on the same tuner). I can, however, switch to a channel on an analog cable tuner and then switch back with no issues. The error that I get on the front end varies between "Error opening jump program file" or an error related to waiting for video buffers. I have done a lot of googling on this issue and it seems that there were reports of this error back in 0.22 and 0.23 but not in 0.24 until 0.24-fixes came out. I found that in 0.24 the ringbuffer time was increased to 10 seconds because Several tickets recently have suggested the default 2 second timeout is potentially too short for certain tuner types and configurations and leads to unnecessary playback failures. This was then changed back for 0.25 and it appears this was something that was backported to 0.24-fixes.

0.24 change:
https://github.com/MythTV/mythtv/commit/0651d1c9ae5f8c965f7e49a3310d0d9962a3df22

0.25 change:
https://github.com/MythTV/mythtv/commit/4e8d935

In my opinion I think that Ticket #9846 is the same issue as this.

I am going to attach my backend log file as well. Note that I have removed a ton of device poll errors from the log since they continued for the duration of the issue.

root@mythtv-backend:~# mythbackend --version
Please attach all output as a file in bug reports.
MythTV Version : v0.25pre-4159-gf2d222c
MythTV Branch : master
Network Protocol : 71
Library API : 0.25.20120123-2
QT Version : 4.7.4
Options compiled in:

linux profile use_hidesyms using_alsa using_oss using_pulse using_pulseoutput using_backend using_bindings_perl using_bindings_python using_bindings_php using_crystalhd using_dvb using_firewire using_frontend using_hdhomerun using_ceton using_hdpvr using_iptv using_ivtv using_joystick_menu using_libcrypto using_libdns_sd using_lirc using_mheg using_opengl_video using_qtwebkit using_qtscript using_qtdbus using_v4l2 using_x11 using_xrandr using_xv using_bindings_perl using_bindings_python using_bindings_php using_mythtranscode using_opengl using_vaapi using_vdpau using_ffmpeg_threads using_live using_mheg

Additional information on my system: I am running a backend server with 2 front ends that both exhibit the same issues. The backend machine is using multiple arrays on a 3ware 9500 PCI card and is a dual AMD Opteron 246 system with 8GB of RAM (running 32bit). Both front end machines are connected over a 10/100 network.

Changed 2 years ago by Bob K Mertz <online@…>

mythbackend log

comment:7 Changed 2 years ago by Bob K Mertz <online@…>

#9177 may also be related

comment:8 Changed 2 years ago by danielk

  • Owner set to danielk
  • Status changed from new to accepted

May be a duplicate of #9177 and #9846.

comment:9 Changed 2 years ago by Bob K Mertz <online@…>

Since upgrading to 0.25 beta the logs that I am looking at are slightly different but the same exact behavior is being exhibited. I now have a HDHR Prime tuner running on this system and it has no issues at all and can switch between channels on that device as much as desired. On my Dish network source using the PVR150 I have to first switch to a channel on another source and then switch back or my system exhibits this behavior. I am attaching a new log file that may (or may not) provide additional information.

root@mythtv-backend:~# mythbackend --version
Please attach all output as a file in bug reports.
MythTV Version : v0.25-beta-173-g111f0ed
MythTV Branch : master
Network Protocol : 72
Library API : 0.25.20120315-2
QT Version : 4.7.4
Options compiled in:

linux profile use_hidesyms using_alsa using_oss using_pulse using_pulseoutput using_backend using_bindings_perl using_bindings_python using_bindings_php using_crystalhd using_dvb using_firewire using_frontend using_hdhomerun using_ceton using_hdpvr using_iptv using_ivtv using_joystick_menu using_libcrypto using_libdns_sd using_libxml2 using_lirc using_mheg using_opengl_video using_qtwebkit using_qtscript using_qtdbus using_v4l2 using_x11 using_xrandr using_xv using_bindings_perl using_bindings_python using_bindings_php using_mythtranscode using_opengl using_vaapi using_vdpau using_ffmpeg_threads using_live using_mheg using_libass using_libxml2

Changed 2 years ago by Bob K Mertz <online@…>

comment:10 Changed 2 years ago by arizonamythtv@…

I'm seeing the same issue. I notice if I try to change the channel through the guide, I get an error that says "mythTV is already using all available inputs". If I try changing the channel by the remote, it attempts to change the channel and then I get the poll errors that the other people have posted then I get a black screen then dumped back to the FE with video buffer errors.

comment:11 Changed 2 years ago by stuartm

  • Milestone changed from unknown to 0.25
  • Priority changed from minor to blocker

comment:12 Changed 2 years ago by mdean

Ref: #10501 , which is reported as fixing this issue at http://www.gossamer-threads.com/lists/mythtv/users/509872#509872 .

comment:13 Changed 2 years ago by arizonamythtv@…

This patch didn't fix my issue. I'm still seeing the same issues as in my post.

comment:14 Changed 2 years ago by danielk

In [55cd239d695a0044b79a38c026dfc95b72d23131]

Refs #9830. Fix some debugging output problems observed in logs on ticket.

comment:15 Changed 2 years ago by danielk

  • Status changed from accepted to infoneeded

From what I can tell we're getting a POLLHUP or POLLNVAL when we poll the data file descriptor.

A POLLNVAL would indicate that the file descriptor has been closed. I don't see any way for this to happen without logging a "StartEncoding? failed" message which I don't see in any of the logs.

A POLLHUP could be seen any time the driver isn't sending data for whatever reason.

I'm attaching a patch which will tell us which one we're really seeing.

Please generate new backend logs with the latest master and this patch applied.

Changed 2 years ago by danielk

comment:16 Changed 2 years ago by Simon Kenyon <simon@…>

i applied the patch and started the backend up and then changed channel

here is the relevant log line (didn't seem worth attaching the whole thing - tell me otherwise and i will)

2012-03-29 08:32:56.206225 E [19438] DeviceReadBuffer? DeviceReadBuffer?.cpp:465 (Poll) - DevRdB(/dev/pvr350_mpeg0): poll error POLLHUP

so we got a POLLHUP

does that tell you anything?

i have upgraded my kernel and linuxtv drivers since first reporting this (with no change in behaviour)
the problem existed on 2.6.33 and now on 3.0.6

in any case kernel is:

Linux sanfrancisco 3.0.6-gentoo #1 SMP PREEMPT Mon Dec 12 22:58:25 GMT 2011 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 6000+ AuthenticAMD GNU/Linux

linuxtv drivers are from media_build
git log shows:

commit 6ac08a51e465af0afc1d53cc55a979e99199272c
Author: Mauro Carvalho Chehab <mchehab@…>
Date: Thu Nov 24 20:34:32 2011 -0200

comment:17 Changed 2 years ago by danielk

Yeah this tells me the driver just isn't sending data but we still have a valid file descriptor.

Mauro explained to me some of the limitations of the streaming implementation for several of the V4L cards. It basically comes down to needing to close the data reading file descriptor while issuing the streamoff/streamon to the device and then reopening it to get the data. I've implemented a proof of concept patch for this in #10519. That patch didn't work for the reporter on that ticket but may work for you. (nocarrier1969 in IRC did some testing last night that looked positive.)

It's a PoC patch which may have some unrelated problems so try it a few times if the first attempt fails.

comment:18 Changed 2 years ago by Simon Kenyon <simon@…>

when i saw #10519 i actually tried that: only with driver_name == "ivtv"

it did not make any difference

comment:19 Changed 2 years ago by danielk

Simon, the patch is not the same as the suggestion by the ticket submitter. That suggestion merely disables streaming API calls for the his particular device, something we were already doing for ivtv. But the ivtv driver has actually supported streaming for some time, just not in a way that is compatible with how MythTV uses the device. The patch attempts to use the streaming API in an ivtv compatible way.

comment:20 Changed 2 years ago by Simon Kenyon <simon@…>

i give up. i thought i responded yesterday.

the patch worked and fixed channel changing for me. thank you, thank you, thank you!

do you still want a log from mythbackend?

comment:21 Changed 2 years ago by danielk

  • Status changed from infoneeded to assigned

Simon, I don't need a log. My message was from before you replied on the other ticket.

comment:22 Changed 2 years ago by arizonamythtv@…

This fixes the ticket except the part of changing the channels from the program guide as I get an error saying the device is busy. I can change the channel by entering the channel number or by going from one tuner than back through the guide.

comment:23 Changed 2 years ago by wagnerrp

  • Resolution set to Fixed
  • Status changed from assigned to closed

Fixes #9830. Refs #10519. Fixes channel change on PVR350.

The drivers for some V4L devices require you to explicitly stop and restart streaming when sending certain ioctl's to the device. We already pause and unpause the recorder when issuing these commands so this adds a close(readfd) to the code that is run on pause and reopens readfd on the unpause code. This also means the DeviceReadBuffer? needs to be reset with the new readfd, so we do that as well.

Branch: master
Changeset: f81f712537b63502814d1f274c7da14196cedd8c

comment:24 Changed 2 years ago by arizonamythtv@…

I pulled the latest from git and confirmed the changes were made per the last post in this ticket. I'm still seeing an issue of I can change the channel without issue by entering the number in my remote but not through the program guide as I get tuner unavailable when I try to change the channel.

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'new'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.