Opened 16 years ago

Closed 15 years ago

#4536 closed defect (fixed)

Recording appears in Watch Recordings too early

Reported by: otto at kolsi dot fi Owned by: Isaac Richards
Priority: minor Milestone: 0.21
Component: mythtv Version: head
Severity: medium Keywords:
Cc: Ticket locked: no

Description

I've noticed following issue with combined be+fe and with separate fe:

Schedule a recording and go to Watch Recordings before recording starts. Recording appears on top of the list as a new (ongoing) recording. Now quickly try to select that recording -> frontend reports that recording file cannot be found.

You can then try to watch it as many times you like but it is never to be found. Also the colour indicating ongoing recording dissapears after couple of tries. If you exit from the Watch Recordings screen and come back, everything is fine again.

This can be very confusing from the user's point of view. Sometimes you want to watch recording immediately after it has started. Also the fact that recording is reported not to be found and the dissapearance of currently recording colour indicator can get you to go and re-schedule the show or watch it using Live-TV. I've done this couple of times..

In one test (with combined be+fe and local recording files) this problem occured if I tried to watch the program 5sec after it appeared in the recordings list. When I waited 20sec everything worked fine.

Attachments (1)

notyetavail.diff (3.0 KB) - added by Mark Buechler <Mark.Buechler@…> 16 years ago.
The patch

Download all attachments as: .zip

Change History (8)

comment:1 in reply to:  description Changed 16 years ago by ylee@…

Replying to otto at kolsi dot fi:

Schedule a recording and go to Watch Recordings before recording starts. Recording appears on top of the list as a new (ongoing) recording. Now quickly try to select that recording -> frontend reports that recording file cannot be found.

You can then try to watch it as many times you like but it is never to be found.

On 0.20.x, I've seen this issue with over-the-air ATSC recordings and, infrequently, FireWire? recordings. With OTA, this can occur if I try playing them before the signal-lock process completes. Reentering Watch Recordings does indeed fix the file-not-found issue, assuming signal lock's now there. With FireWire?, this happens on the rare occasion that the channel doesn't carry a valid video signal for one reason or another; mythbackend doesn't realize this, and finishes normally having "recorded" nothing (although I don't remember if this failure creates a zero-byte file or no file at all, as with the over-the-air recordings).

I'm not sure there is an easy solution to the FireWire? issue because, while it's possible for mythbackend to recognize a FireWire?-connection issue involving a nonresponsive cable box, I don't know if there is a way to check if there actually is valid video coming over FireWire?. (Isn't this part of the reason why music-only channels, with no video, don't work in MythTV?) With OTA, I suppose the solution to the issue is to make sure that the recording-list refresh doesn't occur until the tuning process is complete.

comment:2 Changed 16 years ago by danielk

Resolution: invalid
Status: newclosed

Feature request without patch. The backend inserts the recording into the DB as soon as the recorder begins processing the request. While it is entirely possible to make the Watch Recordings screen check if the file is available and either marking "no data yet" recordings with a different color, or not showing them at all, this would be an added feature. Since there is no patch implementing this feature in this ticket, I'm closing it.

comment:3 Changed 16 years ago by otto at kolsi dot fi

Resolution: invalid
Status: closednew

Daniel, I have to disagree. If there would be new coloring scheme or delay functionality, that would be new feature (I wasn't actually asking these). But if we discard those new ideas, I see two definite bugs currently:

  • when frontend reports that recording file is empty, if you move cursor away from that recording the color indicating ongoing recording disappears
  • once the bug has appeared, you can wait 5min or 30min in Watch recordings screen and frontend never allows you to watch the recording. Frontend does not recover from this problem (not even when next recording is added to the list of recordings). I think it would be okay if e.g. 15sec or even 30sec later file could be watched (when enough data is in disk and in DB) without re-entering Watch Recordings screen.

Changed 16 years ago by Mark Buechler <Mark.Buechler@…>

Attachment: notyetavail.diff added

The patch

comment:4 Changed 16 years ago by Mark Buechler <Mark.Buechler@…>

Added patch as discussed in the ticket. This is compile tested only for now (fearless leader is on).

  • Mark.

comment:5 Changed 16 years ago by cpinkham

Resolution: fixed
Status: newclosed

(In [15656]) Add a new asNotYetAvailable status for recordings in PlaybackBox?. This is for recordings that are ongoing, but the frontend can't access the file yet for whatever reason. This is used instead of setting the recording to asFileNotFound if the file can not be found. This also corrects the font coloring for the recording's info to allow it to be shown in the normal 'recording' color rather than in the 'inactive' color. If you retry to play a recording in the asNotYetAvailable status, PlaybackBox? will attempt to locate the file again and will change the status to asAvailable and play the recording. You no longer have to exit the Watch Recordings screen and reenter in order to do this.

Closes #4536 using patch by Mark Buechler along with a few mods by me.

comment:6 Changed 16 years ago by otto at kolsi dot fi

Resolution: fixed
Status: closednew

Unfortunately [15656] does not fix this issue fully. When program is not yet available, it is shown correctly (pop-up). Also font coloring now works as expected.

But when program is tried to watch too early, it does not became available even if you wait for a long time. Re-entering Watch Recordings screen allows you to watch the program again.

What happens is that in PlaybackBox::play(), availableStatus is asNotYetAvailable and findMatchingProg() finds the ProgramInfo? and availableStatus is changed to asAvailable. But then a bit later, rec->filesize is zero and following error is printed to log:

2008-02-23 13:50:19.250 PlaybackBox::play(): Error, /mnt/space/store/1006_20080223135000.mpg is zero-bytes in size

Play does not recover from this, you always get this sequence until you re-enter the Watch Recordings screen.

As a ugly hack, I added rec->filesize = 1; after line 2675 in playbackbox.cpp. This fixes the issue, but obviously is not a proper fix.

comment:7 Changed 15 years ago by stuartm

Milestone: unknown0.21
Resolution: fixed
Status: newclosed

Original bug is fixed, there is a new ticket for the issue the fix introduced. #6455

Note: See TracTickets for help on using tickets.