MP1.16 RecordingFileHandler: Error while deleting a recording from disk. (1 Viewer)

RonD

Test Group
  • Team MediaPortal
  • December 20, 2011
    911
    278
    SillyValley CA
    Home Country
    United States of America United States of America
    ok, I downloaded the new dll and will try it.

    Were you able to reproduce the problem during testing? I've only seen the Delete Problem when doing normal MP usage using Episode Management. Did not reproduce the problem as a focused tests.
     

    Owlsroost

    Retired Team Member
  • Premium Supporter
  • October 28, 2008
    5,540
    5,038
    Cambridge
    Home Country
    United Kingdom United Kingdom
    Were you able to reproduce the problem during testing?

    I didn't try - mm had worked out why the files couldn't be deleted (because they were not being closed by StreamingServer), so I just (hopefully) fixed the problem in the code.
     

    RonD

    Test Group
  • Team MediaPortal
  • December 20, 2011
    911
    278
    SillyValley CA
    Home Country
    United States of America United States of America
    So far so good 2 nights and no Episode Management “delete problems”. There are about 10 news shows that could cause problems. Yesterday used 2 Remote MP Clients to watch all RecordedTV news shows so each file was accessed using RTSP streaming, no problems with Episode Management. Will check for the 1 or 2 days and report if there are problems.

    EDIT, I'm only going to update this message with daily results for the rest of the week

    no delete problems on 20170509
    no delete problems on 20170510, win10 update did server reboot
    no delete problems on 20170511
    no delete problems on 20170512
     
    Last edited:

    RonD

    Test Group
  • Team MediaPortal
  • December 20, 2011
    911
    278
    SillyValley CA
    Home Country
    United States of America United States of America
    BUT today I saw 3 cases of the following error for recordings ending at 6:01 PM Local. I saw these errors 1 other time in the earlier logs, but this got lost in the noise of the Episode Delete problem. Did not see this error on other days after using the new dll. Maybe this should be a new Forum Thread?

    info from TVService.log
    [2017-05-12 18:01:05,931] [Log ] [3 ] [INFO ] - ChannelStates.DoSetChannelStates took 0 msec
    [2017-05-12 18:01:05,934] [Log ] [scheduler thread] [ERROR] - Exception in Program.Persist() with Message The number of returned rows 0 did not match the expected count of 1+.
    If concurrency control is enabled this may indicate that the record was updated or deleted by another process.
    [2017-05-12 18:01:05,971] [Log ] [scheduler thread] [INFO ] - diskmanagement: recording ABC World News Tonight With David Muir * ended. type:Once max episodes:1

    [2017-05-12 18:01:06,569] [Log ] [scheduler thread] [ERROR] - Exception in Program.Persist() with Message The number of returned rows 0 did not match the expected count of 1+.
    If concurrency control is enabled this may indicate that the record was updated or deleted by another process.
    [2017-05-12 18:01:06,570] [Log ] [scheduler thread] [INFO ] - diskmanagement: recording NBC Nightly News With Lester Holt ended. type:Once max episodes:1

    [2017-05-12 18:01:06,770] [Log ] [scheduler thread] [ERROR] - Exception in Program.Persist() with Message The number of returned rows 0 did not match the expected count of 1+.
    If concurrency control is enabled this may indicate that the record was updated or deleted by another process.
    [2017-05-12 18:01:06,771] [Log ] [scheduler thread] [INFO ] - diskmanagement: recording CBS Evening News With Scott Pelley ended. type:Once max episodes:1
     

    Attachments

    • ProgramPersistServer20170512.zip
      295.9 KB

    mm1352000

    Retired Team Member
  • Premium Supporter
  • September 1, 2008
    21,577
    8,224
    Home Country
    New Zealand New Zealand
    No problems were seen during normal weekly use Episodes were deleted as expected.
    Great. :)

    Unless there are other problems I recommend making this fix "official".
    If you're following the internal 1.17 PR release thread (which I hope you are!) you'll see that Owlsroost's fix is included in the latest test builds. No problem reports there with it either (though I suspect people are not specifically testing the fix), so it's well on its way to being included in the release. Thanks again for your thorough testing and information gathering. It really does make a dev's life much easier. (y)

    BUT today I saw 3 cases of the following error for recordings ending at 6:01 PM Local.
    Aside from the fact that these are error log entries, is there something that's concerning you about this scenario? I mean, I don't see any negative effects. Not that a lack of negative effects is a good excuse to ignore an error message. Rather, I'm just trying to fully understand the scenario.

    I saw these errors 1 other time in the earlier logs, but this got lost in the noise of the Episode Delete problem. Did not see this error on other days after using the new dll. Maybe this should be a new Forum Thread?
    Well, I can say without a shadow of a doubt that the log entries have nothing to do with the [now-resolved] issue in the streaming server. Therefore a new thread would probably be appropriate. However, before we spring for that...

    The meaning of the message is that TV Server failed to unset the recording flag/marker on the program associated with the schedule. That flag/marker is used to determine whether a program should be marked as "recording" (red shading, dot or whatever) in the EPG. I'm pretty sure the reason the failure occurred is that an EPG update ran between 17:47 and 17:53. The original program associated with the schedule would likely have been deleted as part of that update. If the program was deleted (which is consistent with the "...0 did not match the expected count of 1..." part of the log message) there'd be no way to un-flag/un-mark it.

    In other words: I currently think there's nothing further to investigate and that the error message could be ignored. However, again, I want to make sure that I haven't missed something.
     

    RonD

    Test Group
  • Team MediaPortal
  • December 20, 2011
    911
    278
    SillyValley CA
    Home Country
    United States of America United States of America
    ok thanks for looking. I saw those errors 1 other time early looking at the delete problem, figured I'd mention it now. Maybe I'll shift out the xmltv data import to run after 6PM so daily recording are done.

    During hardware system debug I've seen many cases where fix bug #1, #2, #3, start looking around see other errors, somebody says "yea, we saw that 3 weeks ago, forgot to tell you". Then you cancel the flight back home and look into this while your still in the remote office/lab.
     

    mm1352000

    Retired Team Member
  • Premium Supporter
  • September 1, 2008
    21,577
    8,224
    Home Country
    New Zealand New Zealand
    Maybe I'll shift out the xmltv data import to run after 6PM so daily recording are done.
    (y)

    During hardware system debug...
    Oh, for sure!
    Please don't get me wrong.
    I really appreciate you reporting it. (y)
    On this occasion I think the log entry being an error is a bit misleading (sorry). As long there's nothing else going on in connection with it I think we can safely leave it. The main reason I'm not going further and trying to eliminate or downgrade the log entry to avoid further/future misunderstanding is that the entry is from the database level and TVE 3.5 completely replaces the database access layer.
     

    Users who are viewing this thread

    Top Bottom