Page 3 of 8 FirstFirst 12345 ... LastLast
Results 21 to 30 of 74

Thread: Skipping issue on PCH

  1. #21
    Join Date
    May 2006
    Location
    Canada
    Posts
    21,244
    Sub did you change anything regarding the initial resume from the Recording in 2.2.6? The post from Shiek Yerbouti and jksmurf show the resume being sent before the NMT is ready to receive it. It would partially explain bgowland's problem since a resume seek before a file is played could be ignored if the delay was long enough.

    Martin

  2. #22
    Join Date
    Dec 2004
    Location
    West Yorkshire, UK
    Posts
    4,497
    Martin - did you see my post #20? I think our posts may have overlapped and the pages have wrapped now. If I can get logging to the share working, I'll go and test and see if I can provide more details.

  3. #23
    Join Date
    Nov 2003
    Location
    NextPVR HQ, Wellington, New Zealand
    Posts
    76,317
    Quote Originally Posted by mvallevand View Post
    Sub did you change anything regarding the initial resume from the Recording in 2.2.6? The post from Shiek Yerbouti and jksmurf show the resume being sent before the NMT is ready to receive it. It would partially explain bgowland's problem since a resume seek before a file is played could be ignored if the delay was long enough.
    No, I dont think anything has changed. Resuming has always initiated playback, if a PCH/MVP then sleep for a short period, then seeked to the resume spot.

    The duration of that sleep can be tweaked with the /Settings/General/PreResumeDelay. The default was 500ms.

  4. #24
    Join Date
    May 2006
    Location
    Canada
    Posts
    21,244
    Quote Originally Posted by bgowland View Post
    Yes, I setup a local user for the share which has full control. Looking at the npvr.cgi I can only see one line with redirects...

    Code:
    sh -c /etc/mvpmc/startmeup 2>/dev/null >/dev/null &
    ...assuming that's the correct line, should I change both /dev/null entries to point to a log file?
    I want both so try

    Code:
    sh -c /etc/mvpmc/startmeup &>/etc/mvpmc/foobar &
    Martin

  5. #25
    Join Date
    May 2006
    Location
    Canada
    Posts
    21,244
    Quote Originally Posted by sub View Post
    The duration of that sleep can be tweaked with the /Settings/General/PreResumeDelay. The default was 500ms.
    Ok I will do some testing I don't normally play from Recordings. Chris/Brian I suggest that you try adjusting this value.

    Martin

  6. #26
    Join Date
    Jun 2007
    Location
    St. Paul, MN, USA
    Posts
    530
    Quote Originally Posted by mvallevand View Post
    Ok I will do some testing I don't normally play from Recordings. Chris/Brian I suggest that you try adjusting this value.
    FYI - Mine is set at 4500--I think from Martin's advice a long time back when I was having problems with resumes not working.

    Edit: Yeah, here it was:
    Quote Originally Posted by mvallevand View Post
    To get around another .33 issue if you want it to work on the PCH try using this
    <PreResumeDelay>4500</PreResumeDelay>
    This is only of value on the PCH however, and doesn't fix the 12:48 problem with Timing.Info
    Martin
    Last edited by BrettB; 2011-09-13 at 01:17 AM.

  7. #27
    Join Date
    Dec 2004
    Location
    West Yorkshire, UK
    Posts
    4,497
    Quote Originally Posted by mvallevand View Post
    I want both so try

    Code:
    sh -c /etc/mvpmc/startmeup &>/etc/mvpmc/foobar &
    I tried this (using foobar, log.txt etc etc) and the files are created which shows the PCH has write access to my mvpmc share but, when I use this command-line, I never see the npvr main menu on my TV - it goes through the motions but I just end up with a blank screen and the log file is always 0KB. I've reverted to the previous 'sh' command until I have more time to play tomorrow.

    Quote Originally Posted by mvallevand View Post
    Ok I will do some testing I don't normally play from Recordings. Chris/Brian I suggest that you try adjusting this value.
    The issue of this thread isn't to do with 'resume' - it's to do with the unexplained drop back to the Recordings menu. I will try tweaking that resume setting in case it helps recover but that's actually just a side-effect of the drop out. The outstanding question is why, when I've been able to successfully skip through earlier parts of a recording, does it suddenly drop out to the Recordings screen? No error messages in the logs and even a log entry where it seems to be saving the current position as if I've requested a stop when all I did was press the Right skip button.

  8. #28
    Join Date
    May 2006
    Location
    Canada
    Posts
    21,244
    Quote Originally Posted by bgowland View Post
    The issue of this thread isn't to do with 'resume' - it's to do with the unexplained drop back to the Recordings menu. I will try tweaking that resume setting in case it helps recover but that's actually just a side-effect of the drop out. The outstanding question is why, when I've been able to successfully skip through earlier parts of a recording, does it suddenly drop out to the Recordings screen? No error messages in the logs and even a log entry where it seems to be saving the current position as if I've requested a stop when all I did was press the Right skip button.
    I am not trying to solve the drop out at this point without client side logs. The "abort" logic is designed to have NPVR treat a file read error as a stop so the resume point is valid. In you're example you should have been able to quickly resume even after the failure. I can't explain why NPVR didn't request a resume.

    Martin

  9. #29
    Join Date
    May 2006
    Location
    Canada
    Posts
    21,244
    Quote Originally Posted by sub View Post
    No, I dont think anything has changed. Resuming has always initiated playback, if a PCH/MVP then sleep for a short period, then seeked to the resume spot.

    The duration of that sleep can be tweaked with the /Settings/General/PreResumeDelay. The default was 500ms.
    I did some testing and didn't notice any changed behaviour, I run with just 500ms and the mvpmcx2 safeguards still work for me.

    Martin

  10. #30
    Join Date
    Jul 2006
    Location
    Schagen, the Netherlands
    Posts
    856
    Quote Originally Posted by mvallevand View Post
    I did some testing and didn't notice any changed behaviour, I run with just 500ms and the mvpmcx2 safeguards still work for me.

    Martin
    I did switch to HD on a lot of channels, maybe that's less forgiving. I'll just test some more.

    Chris
    i5 750 4GB RAM, W7 Home Premium 64 bit, Digital Devices Cine CT V6 dual DVB-C, KNC One DVB-C, OSCam on a Raspberry Pi with a Smargo Smartreader+, Egreat M34A, Popcorn Hour A-100, Samsung 40F8000.

Posting Permissions

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