Opened 13 years ago

Closed 13 years ago

#9218 closed defect (Fixed)

0.24 Cutlist Editor Unstable

Reported by: Scott Harris <snharris99@…> Owned by: markk
Priority: critical Milestone: 0.24.1
Component: MythTV - Video Playback Version: 0.24
Severity: high Keywords:
Cc: Ticket locked: yes

Description

While trying to skip (regardless of skip amount) in the cut list editor, the editor ultimately locks up. The only remedy is to hard kill the frontend process and relaunch it. Occurs on all my systems which are all Mythbuntu 10.04 (32&64 bit) / Mythtv 0.24.0+fixes27204-0ubuntu0+mythbuntu1.

Not consistent across all recordings, however consistent with the recordings it happens with in that it will happen every time with those recordings. Also not consistent in when / where it will happen. Sometimes you can skip a few times before it locks, sometimes it locks on the first attempt. In my case, all the problems appear to be recorded from one channel which is a 1080i signal.

I have tried using different playback profiles to attempt to eliminate vdpau as a culprit, with the same results.

Nothing noteworthy in the logs, however here is a sample output from -v playback, where the second skip is where the lock occurred.

2010-11-13 08:09:21.823 VDP: LoadBestPreferences(1920x1088, 0)
2010-11-13 08:09:21.824 VDP: GetFilteredDeint(vdpaubasic) : vdpau -> 'vdpaubasic'
2010-11-13 08:09:21.824 VidOutVDPAU: Enabled deinterlacing.
2010-11-13 08:09:21.858 VidOutVDPAU: UpdatePauseFrame() UUUUUUUDuADLDUUUU
2010-11-13 08:09:24.257 AFD: DoFastForward(357 (340), do discard frames)
2010-11-13 08:09:24.257 Dec: DoFastForward(357 (340), do discard frames)
2010-11-13 08:09:24.257 Dec: FindPosition(357, search not adjusted) --> 
			[23:345(22371812),24:360(22769432)]
2010-11-13 08:09:24.258 AFD: SeekReset(345, 12, do flush, do discard)
2010-11-13 08:09:24.259 AFD: SeekReset() flushing
2010-11-13 08:09:24.259 VidOutVDPAU: DiscardFrames(1)
2010-11-13 08:09:24.259 VideoBuffers::DiscardFrames(1): UUUUUUUAUAAAAUUUU
2010-11-13 08:09:24.259 VideoBuffers::DiscardFrames(): AAAAAAAAAAAAAAAAA -- done()
2010-11-13 08:09:24.259 VideoBuffers::DiscardFrames(1): AAAAAAAAAAAAAAAAA -- done
2010-11-13 08:09:24.260 VidOutVDPAU: DiscardFrames() 3: AAAAAAAAAAAAAAAAA -- done()
2010-11-13 08:09:24.457 Player(0): ClearAfterSeek(0)
2010-11-13 08:09:24.572 VidOutVDPAU: UpdatePauseFrame() AuAAALAAAAAAAAAAA
2010-11-13 08:09:25.253 AFD: DoFastForward(387 (358), do discard frames)
2010-11-13 08:09:25.253 Dec: DoFastForward(387 (358), do discard frames)
2010-11-13 08:09:25.254 Dec: FindPosition(387, search not adjusted) --> 
			[25:375(23162728),26:390(23554144)]
2010-11-13 08:09:25.255 AFD: SeekReset(375, 12, do flush, do discard)
2010-11-13 08:09:25.255 AFD: SeekReset() flushing
2010-11-13 08:09:25.255 VidOutVDPAU: DiscardFrames(1)
2010-11-13 08:09:25.255 VideoBuffers::DiscardFrames(1): AUAAAAAAAAAAAAAAA
2010-11-13 08:09:25.255 VideoBuffers::DiscardFrames(): AAAAAAAAAAAAAAAAA -- done()
2010-11-13 08:09:25.255 VideoBuffers::DiscardFrames(1): AAAAAAAAAAAAAAAAA -- done
2010-11-13 08:09:25.255 VidOutVDPAU: DiscardFrames() 3: AAAAAAAAAAAAAAAAA -- done()
Killed

Attachments (3)

9218.backtrace (59.8 KB) - added by Jim Stichnoth <stichnot@…> 13 years ago.
radeon_output.txt (26.3 KB) - added by anonymous 13 years ago.
Log of radeon system
nvidia_output.txt (7.0 KB) - added by anonymous 13 years ago.
Nvidia output

Download all attachments as: .zip

Change History (13)

comment:1 Changed 13 years ago by paul@…

I have the same issue with recordings from BBC HD & BBC One HD. Not tried with ITV1 HD yet but will later today. Problem occurs on both Linux and Mac OS frontends. Results in hard lock which needs the process killing.

comment:2 Changed 13 years ago by paul@…

Have tried a recording from ITV1 HD and that worked fine - no lock up encountered.

comment:3 Changed 13 years ago by robertm

Resolution: Duplicate
Status: newclosed

Dupe of #9144

Changed 13 years ago by Jim Stichnoth <stichnot@…>

Attachment: 9218.backtrace added

comment:4 Changed 13 years ago by Jim Stichnoth <stichnot@…>

Hard to believe this is a dupe of #9144.

I attached gdb to the deadlocked mythfrontend process and got a backtrace (attached). I have several patches on my system, so don't necessarily trust the line numbers. The edit thread is waiting on the decoder thread. It appears that the decoder thread is calling AvFormatDecoder::ProcessDVBDataPacket() which is calling TeletextDecoder::Decode() (which seems strange for a U.S. OTA recording) which is blocked trying to lock the OSD. This deadlocks because the editor thread acquired the OSD lock in TV::ProcessKeypress?().

comment:5 Changed 13 years ago by anonymous

I also think it is hard to believe this is a duplicate of #9144 since I use a backend+frontend with an nvidia card (vdpau output) and a remote frontend with an ATI card (free driver, opengl output) and I get the unstability while editing the cutlist with both systems.

comment:6 Changed 13 years ago by stuartm

Resolution: Duplicate
Status: closednew

comment:7 Changed 13 years ago by anonymous

I have the same problem.

comment:8 Changed 13 years ago by stuartm

Ticket locked: set

I will start banning people for anonymous 'me toos'. It's clearly stated in the rules that this is unacceptable.

comment:9 Changed 13 years ago by stuartm

Component: MythTV - GeneralMythTV - Video Playback
Milestone: unknown0.24.1
Owner: set to markk
Priority: minorcritical
Severity: mediumhigh
Status: newassigned

Changed 13 years ago by anonymous

Attachment: radeon_output.txt added

Log of radeon system

Changed 13 years ago by anonymous

Attachment: nvidia_output.txt added

Nvidia output

comment:10 Changed 13 years ago by markk

Resolution: Fixed
Status: assignedclosed

(In [27213]) Teletext fixes.

  • add a TryLockOSD method to MythPlayer? which will wait 50ms for the

lock and use this in the teletext decoder.

  • Only decode teletext data if teletext based captions are enabled.

The latter will introduce a certain amount of delay between enabling teletext items and their display on screen as the teletext data is no longer continuously cached.

Closes #9218

Note: See TracTickets for help on using tickets.