Race condition on delete with video preview

[garrick@…]

This is a pretty easy frontend lockup to reproduce. In the playback screen, move focus to a recorded show (right cursor), then move focus back to the title (left cursor), and hit delete. The frontend will now be locked up. The gf does this about once a week :)

I'm attaching a patch that simply ignores the delete if inTitle.

[garrick@…]

ignore delete key when inTitle in playback screen

[garrick@…]

Since the patch doesn't show much useful context, it is at the top of PlaybackBox::deleteSelected()

void PlaybackBox::deleteSelected() {

previewVideoState = kStopping;

if (inTitle)

return;

[skamithi]

i cannot reproduce the lockup.. can anyone else ? works everytime for me. it shows the delete prompt.

[Mark Spieth]

I can do it too. but its not as bad as it used to be. happens on my low power xbox FE. If I delete and press back/ESC before the delete is complete I can get back to the previous menu. Sometimes it takes several minutes before it responds to the remote. Sometimes it works within a few seconds. I suspect the FE is trying to play preview the just deleted file and then it goes away in a way it doesnt like. No logs but can get some if required. If it goes bad I have to restart myth FE to use it again. reasonably current HEAD.

[danielk]

When you initially enter "Watch Recordings" does it take a long time to load? If so you may be waiting on the recordings list, a reload happens one second after the delete. Otherwise, if your SVN head is older than about two weeks you may be getting hit with the reschedule which gets scheduled right after a delete.

If the problem is with the preview video playback, just turn off that feature; skamithi is working on a better preview video player in #843.

[anonymous]

The problem I'm seeing doesn't seem related to preview or any actual deletes. It is just simply that pressing the delete button freezes FE (no delete menu shows up) if a title is focused after a left cursor from a show.

This seems unrelated to markspieth's problem.

Initially entering "Watch Recordings" is fine. It takes a reasonable second to grab everything from the database and paint the screen.

1. Enter "Watch Recordings"
2. right cursor to a show (focus is now in the right pane on an episode)
3. left cursor back to the left pane
4. hit delete (the "red" button on my remote)
5. FE is now locked up (no delete menu appeared)

This is 100% reproducible for me. It's not racey at all.

I'm using current ATrpms' 20-fixes line.

[garrick@…]

I just found out that the preview is involved. Before cursor left, you must be focused on the show long enough for the preview to start.

1. Enter "Watch Recordings"

2. right cursor to a show

3. wait a second for the preview to start

4. left cursor back to category

5. hit delete and FE will be locked up

It appears to me that killPlayerSafe() isn't returning.

deleteSelected()->remove()->showDeletePopup()->initPopup()->killPlayerSafe()

[Mark Spieth]

entry duration before watchrecordings is shown is fast with or without items in watch recordings also it only locks up when the last recording is deleted. if a recording is deleted and its not the last one then everything is ok. also only seems to happen on my slow resource starved machine. 733MHz+64MB

[garrick@…]

Replying to markspieth:

also it only locks up when the last recording is deleted. if a recording is deleted and its not the last one then everything is ok. also only seems to happen on my slow resource starved machine. 733MHz+64MB

You are describing a different problem. The problem I'm reporting doesn't require any previous deletes.

The reported problem seems to be related to killPlayerSafe() waiting forever for the preview player to stop when it wasn't actually running.

[danielk]

Stanley, this should be fixed by your PiP rewrite, can you close this when that goes into SVN head (which may be a while from now, admittedly).

[garrick@…]

This bug is still present in 0.20.2. Since I originally reported this bug, I've just disabled the previews. Can the 2 line patch be applied to 0.20-fixes?

[cpinkham]

Based on the description in comment #8, I believe this ticket was fixed by [15392]. Someone can reopen if they can reproduce the issue. Tickets #4421 and #3099 described similar circumstances.

[garrick@…]

Will this be checked into release-0-20-fixes? If so, then I'll test on the next atrpms release.

The other comments don't match the problem that I'm describing. Despite the summary change, I'm seeing a race condition because it happens 100% of the time. It doesn't matter how long I wait before hitting "delete".