Results 1 to 10 of 79

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

Hybrid View

  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
    May 2006
    Location
    Milwaukee,WI
    Beans
    6,284
    Distro
    Xubuntu 14.04 Trusty Tahr

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

    ok, i am running
    Code:
    MythTV Version : v0.25.2-15-g46cab93
    MythTV Branch : fixes/0.25
    Network Protocol : 72
    Library API : 0.25.20120506-1
    QT Version : 4.8.1
    and my PVR-350 and PVR-500 seem to be working BUT I am getting massive ivtv mpg buffer overflows and it's dropping data. I have added some module options to /etc/modprobe.d/ivtv.conf and /etc/modprobe.conf and they are
    Code:
    options ivtv enc_mpg_buffers=16 enc_yuv_buffers=20 enc_pcm_buffers=640 debug=3
    I'll report back if that error message stops appearing my dmesg output. The error looks like the following:
    Code:
    [15678.012796] ivtv0: All encoder MPG stream buffers are full. Dropping data.
    [15678.012804] ivtv0: Cause: the application is not reading fast enough.
    [15678.181416] ivtv0: All encoder MPG stream buffers are full. Dropping data.
    [15678.181425] ivtv0: Cause: the application is not reading fast enough.
    [15678.314549] ivtv0: All encoder MPG stream buffers are full. Dropping data.
    [15678.314558] ivtv0: Cause: the application is not reading fast enough.
    [15678.678262] ivtv0: All encoder MPG stream buffers are full. Dropping data.
    [15678.678270] ivtv0: Cause: the application is not reading fast enough.
    [15678.848255] ivtv0: All encoder MPG stream buffers are full. Dropping data.
    [15678.848263] ivtv0: Cause: the application is not reading fast enough.

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
  •