Page 1 of 8 123 ... LastLast
Results 1 to 10 of 79

Thread: PVR-500 ivtv failures since 0.25 upgrade (in April)

  1. #1
    Join Date
    Jul 2008
    Location
    North Central Indiana
    Beans
    248

    PVR-500 ivtv failures since 0.25 upgrade (in April)

    BE/FE (with remote FEs too) on MB 10.04 x86_64 with MythTV 0.25 (currently 2:0.25.0+fixes.20120608.648f0ae-0ubuntu0mythbuntu1) using one PVR-500 connected to Dish Network receiver using tuner0/S-Video1 and an OTA digital receiver feeding NTSC to tuner1/Composite1:

    Ever since upgrading to 0.25 a few days after release, I've had never ending trouble with the PVR-500 becoming unresponsive with I/O errors at random times but becoming increasingly likely the longer the BE goes between restarts (and/or ivtv driver reset [with rmmod and modprobe]). This creates 0-bit recordings in MythTV and breaks LiveTV. Backend logs show 'StartEnconding Failed' and 'socket went unconnected' errors.

    If I quit MyhthTV frontend and stop the backend (and wait for threads to exit), 'cat /dev/video0 > ./test.mpg' also produces 0-bit test.mpg (and cat does not exit cleanly). v4l2-ctl commands will error out.

    Once I do a 'sudo rmmod ivtv' and 'sudo modprobe ivtv', the card will work properly for a random period of time (and may even fail upon its very first use by MythTV).

    Within MythTV, no particular pattern of channel changes or other usage scenarios seems to impact the likelihood of the card failing at any particular time; LiveTV is no more likely to create a problem than scheduled recordings. All capture cards (not just on the BE) have been deleted and reconfigured several times (with at least one iteration of removing all cards, all video sources, and rebuilding channels from scratch). In fact, I've gotten into the practice of removing and reconfiguring the capture cards after each and every MythTV update...their tuning timeout is the 12s default. I have tried running with ONLY the /dev/video0 (connected to Dish) configured as well (to no help).

    Outside of MythTV I have not been able to bork the card; no amount of channel changes, v4l2-ctl commands, connects/disconnects with vlc/mplayer/whatever elicits the symptoms.

    This began immediately on upgrade and has never stopped malfunctioning on any release since.

    I've searched and probed:
    It is exactly the symptoms noted in this (now closed) bug: http://code.mythtv.org/trac/ticket/9846, except that it is not confined to LiveTV. It appears this bug may be a duplicate of 9830 which has been fixed, and the fixes are in the version I'm using. It also may be related to 9177 which is now closed as invalid.

    I have no idea how to proceed in debugging this issue other than to try the card in a totally fresh 10.04 or 12.04 installation, but I don't relish that thought much.

    Any ideas?

  2. #2
    Join Date
    Mar 2007
    Location
    Christchurch, NZ
    Beans
    3,239

    Re: PVR-500 ivtv failures since 0.25 upgrade (in April)

    Quote Originally Posted by anonymousdog View Post
    BE/FE (with remote FEs too) on MB 10.04 x86_64 with MythTV 0.25 (currently 2:0.25.0+fixes.20120608.648f0ae-0ubuntu0mythbuntu1) using one PVR-500 connected to Dish Network receiver using tuner0/S-Video1 and an OTA digital receiver feeding NTSC to tuner1/Composite1:

    Ever since upgrading to 0.25 a few days after release, I've had never ending trouble with the PVR-500 becoming unresponsive with I/O errors at random times but becoming increasingly likely the longer the BE goes between restarts (and/or ivtv driver reset [with rmmod and modprobe]). This creates 0-bit recordings in MythTV and breaks LiveTV. Backend logs show 'StartEnconding Failed' and 'socket went unconnected' errors.

    If I quit MyhthTV frontend and stop the backend (and wait for threads to exit), 'cat /dev/video0 > ./test.mpg' also produces 0-bit test.mpg (and cat does not exit cleanly). v4l2-ctl commands will error out.

    Once I do a 'sudo rmmod ivtv' and 'sudo modprobe ivtv', the card will work properly for a random period of time (and may even fail upon its very first use by MythTV).

    Within MythTV, no particular pattern of channel changes or other usage scenarios seems to impact the likelihood of the card failing at any particular time; LiveTV is no more likely to create a problem than scheduled recordings. All capture cards (not just on the BE) have been deleted and reconfigured several times (with at least one iteration of removing all cards, all video sources, and rebuilding channels from scratch). In fact, I've gotten into the practice of removing and reconfiguring the capture cards after each and every MythTV update...their tuning timeout is the 12s default. I have tried running with ONLY the /dev/video0 (connected to Dish) configured as well (to no help).

    Outside of MythTV I have not been able to bork the card; no amount of channel changes, v4l2-ctl commands, connects/disconnects with vlc/mplayer/whatever elicits the symptoms.

    This began immediately on upgrade and has never stopped malfunctioning on any release since.

    I've searched and probed:
    It is exactly the symptoms noted in this (now closed) bug: http://code.mythtv.org/trac/ticket/9846, except that it is not confined to LiveTV. It appears this bug may be a duplicate of 9830 which has been fixed, and the fixes are in the version I'm using. It also may be related to 9177 which is now closed as invalid.

    I have no idea how to proceed in debugging this issue other than to try the card in a totally fresh 10.04 or 12.04 installation, but I don't relish that thought much.

    Any ideas?
    Try deleting all your tuners in mythtv and adding them again. Don't worry you won't need to re-tune or anthing, once you have added them again simply reconnect them to their sources.

  3. #3
    Join Date
    Jul 2008
    Location
    North Central Indiana
    Beans
    248

    Re: PVR-500 ivtv failures since 0.25 upgrade (in April)

    Quote Originally Posted by nickrout View Post
    Try deleting all your tuners in mythtv and adding them again. Don't worry you won't need to re-tune or anthing, once you have added them again simply reconnect them to their sources.
    Thanks, Nick,

    I do that every time symptoms manifest and on every upgrade (as written above)...as per this procedure:
    * Stop (frontend[s] and) backend and ensure they are stopped
    * If ivtv is broken, rmmod/modprobe ivtv and test card
    * Backend setup: delete all cards, exit (just to ensure changes get written to DB), don't restart the service or run mythfilldb
    * Backend setup: add cards back, connect to inputs, exit
    * Restart backend, run mythfilldb
    * Start frontend and test

    At least once (and maybe twice) I went so far as to delete all cards and all video sources, then reconfigure and rebuild channels (on the DTV input) from scratch.

    The 0.23 timeout on the cards had been (IIRC) 3s; now it's 12s.

    It doesn't help.

    I've even run with just one card/tuner/input configured...no help.

  4. #4
    Join Date
    Jul 2008
    Location
    North Central Indiana
    Beans
    248

    Re: PVR-500 ivtv failures since 0.25 upgrade (in April)

    Also, when both tuners are configured, I can lose one tuner (i.e., making 0-bit recordings, not responding to v4l2-ctl, etc.), but, depending on unknown conditions, I *may* still be able to tune to the other card *once only*. After that one use, that card too will become unresponsive. In fact, in many failures with LiveTV, the frontend will fail the first card then tune to the second successfully...the first card will be borked until ivtv is reloaded.

    I've only one time seen MythTV fail to tune to the card on it's first use (after ivtv reload or a reboot), and I cannot guaranty that I had successfully reset ivtv that time (i.e., I hadn't done 'cat /dev/video0 > ./test.mpg' to test before starting the backend and trying to tune it with the frontend).

  5. #5
    Join Date
    Mar 2007
    Location
    Christchurch, NZ
    Beans
    3,239

    Re: PVR-500 ivtv failures since 0.25 upgrade (in April)

    Sorry I clearly didn't read your first post fully.

    About the only thing I can suggest is that perhaps your card is dying? How do the capacitors look?

    Or different PCI slot?

    Or a modprobe -r ivtv && modprobe ivtv in your channel change script? (so it gets executed before each recording).

  6. #6
    Join Date
    Jul 2008
    Location
    North Central Indiana
    Beans
    248

    Re: PVR-500 ivtv failures since 0.25 upgrade (in April)

    Quote Originally Posted by nickrout View Post
    Sorry I clearly didn't read your first post fully.

    About the only thing I can suggest is that perhaps your card is dying? How do the capacitors look?

    Or different PCI slot?

    Or a modprobe -r ivtv && modprobe ivtv in your channel change script? (so it gets executed before each recording).
    The board looks fine, and I've stressed tested it with other software (including some scripted punishment that did several thousand 'input change, cat to file, file test' loops). I've left the system running for two days with mythtv-backend off and disabled, running the punishment script periodically. No misbehavior from the card.

    I can't rule out hardware definitively unless I swap it for another card, but I think it's super unlikely to be the cause: The hardware and system were ROCK solid (on 10.04.4 x86_64 0.23) for over a year (with a DB and recordings going back to May 2008), and symptoms started within an hour of upgrading to 0.25. That much correlation is hard to overlook.

    I'll try the modprobe channel change kludge (for testing purposes); at least it's easy to implement.
    Last edited by anonymousdog; June 10th, 2012 at 07:29 AM. Reason: disable smiles in this post

  7. #7
    Join Date
    Jun 2010
    Beans
    8

    Re: PVR-500 ivtv failures since 0.25 upgrade (in April)

    Hi,

    Just wanted to confirm that this is a software issue, I have a system that was recently upgraded to 0.25 from 0.24 (using the ppa with the latest fixes, http://www.mythbuntu.org/repos). After the upgrade the system starts showing the same symptoms like the thread-creator has described. In my case though, I have a Hauppauge WinTV PVR-250 but this card is also using the ivtv driver. I also get 0 byte files issuing cat /dev/video0 > ./test.mpg, unloading and loading ivtv kernel module resolved this issue.

    The backend and frontend are both running Ubuntu 10.04.4 LTS, with all available updates applied.

    Any progress on the root cause?

  8. #8
    Join Date
    Jul 2008
    Location
    North Central Indiana
    Beans
    248

    Re: PVR-500 ivtv failures since 0.25 upgrade (in April)

    None. I've got nothing.

    Symptoms persist with MythTV but cannot be elicited with any other use of the card.

    Card looks good, temps are cool, lots of air flow.

    I have noticed that most failures take about 24-36 hrs to manifest (from the last ivtv restart)...almost never more than 48hrs.

    I'm buying a new hard drive so I can try a fresh install (prob 12.04 x86_64 though) without touching the current boot disk.

  9. #9
    Join Date
    Jun 2010
    Beans
    8

    Re: PVR-500 ivtv failures since 0.25 upgrade (in April)

    After googling a bit is seems that a lot of users are having this issue. Some have added a cronjob to unload and reload the ivtv drivers every now and then...

    I think this is the actual ticket for this item:

    http://code.mythtv.org/trac/ticket/10732

    It has priority minor and severity medium so this doesn't seem like a bit issue right now for the MytvTV developers.

    The ticket has one ides of changing the IO scheduler policy to realtime, this seems to have helper for some users. I will try that now... Wife acceptance is pretty low on this bug...

  10. #10
    Join Date
    Jul 2008
    Location
    North Central Indiana
    Beans
    248

    Re: PVR-500 ivtv failures since 0.25 upgrade (in April)

    Quote Originally Posted by dnilsson View Post
    I think this is the actual ticket for this item:

    http://code.mythtv.org/trac/ticket/10732

    It has priority minor and severity medium so this doesn't seem like a bit issue right now for the MytvTV developers.
    ...which makes no sense to me since it breaks basic utilization of the most popular, most widely supported, and most recommended family of analog capture cards. I keep seeing it written that there is an expectation that "almost everyone" will have (by now) abandoned SD for HD capture cards (and that, because of that expectation, problems with SD cards are low or no priority). I'm willing to bet that expectation is faulty, that there is a huge installed base of SD cards (especially mpeg cards supported by ivtv) still in production in the wild.

    Quote Originally Posted by dnilsson View Post
    The ticket has one ides of changing the IO scheduler policy to realtime, this seems to have helper for some users. I will try that now... Wife acceptance is pretty low on this bug...
    Thanks for noting this ticket; I had no found it. I'm glad to know that this bug effects other distros including MB 12.04 (since I've been arranging to upgrade in an attempt to avoid the bug).

    How are you implementing that IO scheduler hack? Are you adding the above line to the service startup script?

Page 1 of 8 123 ... LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •