Editing Functionality Broken

[Simon Kenyon <simon@…>]

well actually it is the editing functions in mythtv

i was near the end of a recording and i wanted to see an earlier bit again (see summary), and i set it to jump in 20 seconds chunks.

as i hit <left><left> the following was observed:

i went backwards in the recording and the picture was replaced (for a very short time) by the correct frame; only to be immediately replaced with the frame that was displayed as i entered edit mode.

for small jumps (1 second, 0.5 seconds, 1 frame; not sure about 5 seconds) the behaviour is as expected, although there does seem to be some frame strangeness (like 2 frames back, one forward).

this is with trunk svn #21738.

have not updated to latest for fear of the current theme updates

[robertm]

Also observed here.

[Simon Kenyon <simon@…>]

just tested with 21873 and it appears to work

for what it is worth; before i rebuilt i rm -rf /usr/share/mythtv to clear out all the themes. then when i ran i changed to a graphite and then (quickly) to ProjectGrayhem?-wide i also changed the OSD theme to ProjectGrayhem?

[Shane Shrybman]

Thanks for reporting back Simon.

Robert, just re-open if needed.

[Janne Grunau]

reopened for Simon:

this is still a problem if use use the "Normal" display profile. anything more than a 5 second skip causes the original frame to be displayed it works properly with the CPU++ profile

this is with trunk svn #21975 on a NVidia GeForce?? 8300 running nvidia-drivers on gentoo (AMD64 X2)

old problem description: i was near the end of a recording and i wanted to see an earlier bit again (see summary), and i set it to jump in 20 seconds chunks. as i hit <left><left> the following was observed: i went backwards in the recording and the picture was replaced (for a very short time) by the correct frame; only to be immediately replaced with the frame that was displayed as i entered edit mode.

for small jumps (1 second, 0.5 seconds, 1 frame; not sure about 5 seconds) the behaviour is as expected, although there does seem to be some frame strangeness (like 2 frames back, one forward).

this is with trunk svn #21738. have not updated to latest for fear of the current theme updates

[robertm]

The issue appears to be an issue when using the Xv renderer. Switching to GL or VDPAU solves the issue. It also appears to only affect low resolution editing (480i in my case), while 720p and 1080i behave nicely regardless or renderer.

[Shane Shrybman]

Can you verify that this still happens with current trunk? There have been some seeking related updates there.

If it is reproducible, can you supply a mythfrontend -v playback log?

[Simon Kenyon <simon@…>]

it still happens with the "Normal" profile. will take a log now

[Simon Kenyon <simon@…>]

running mythfrontend in a 1024x576 window on a 1280x1024 screen - svn trunk 22418

[robertm]

Fixed sometime before 22544.

[robertm]

jarle in #mythtv-users reports this problem still present in .22-fixes r22858, reopening. Seems exclusive to Xv-blit as a renderer.

[Stuart Auchterlonie]

Bumping open 0.22 milestone tickets to 0.24

[stefan.becker@…]

Problem observed with 0.23-rc2 & -rc3 (currently: 0.23-0.10.rc3.fc13 (r24414)). This independent of the renderer, i.e. it happens with xv-blit & opengl. Only jump mode "1 Frame" works correctly.

For more details see duplicate #8424.

Can the milestone be set to 0.23? This problem makes cutlist editing kind of a guessing game :-(

[robertm]

Have not seen this in trunk with the new MythUI OSD. Editing still broken in the sense that it does some funky stuff like lose your cuts, but this particular bug seems solved.