Opened 10 years ago

Closed 10 years ago

#9904 closed Bug Report - General (fixed)

All black/incorrect previews

Reported by: beirdo Owned by:
Priority: minor Milestone: 0.25
Component: MythTV - General Version: Master Head
Severity: medium Keywords:
Cc: Ticket locked: no


I remember fixing this before (at that point it was an incorrect seektable being generated during recording). I'm seeing black or nearly completely black previews again for a number of my recordings.

This time it seems to be limited only to analog captured MPEG2 from my hvr2250. MPEG2 from the HDHomerun seems OK, as does H.264 from the HDPVR, and digital captured OTA MPEG2 from the hvr2250.

Change History (3)

comment:1 Changed 10 years ago by xris

After restarting my backend via ssh, I had a couple of these randomly pop up in my terminal session:

libpng warning: Ignoring bad adaptive filter type
libpng warning: Ignoring bad adaptive filter type
libpng error: invalid block type
QImage::scaled: Image is a null image

The only reasonable source for these messages is the backend. Maybe it helps.

FWIW, I see the preview issue in about half of my recordings (firewire and hdhomerun), with no particular pattern -- mixed results from the same shows, channels, etc. More annoying is that shows without previews can't be deleted from the frontend because the files "are in use by preview generation" (or something to that extent).

comment:2 Changed 10 years ago by xris

hmm, just occurred to me that the aforementioned error might have happened when I loaded up my recordings list from mythweb. I bet it's trying to generate a resized thumbnail from a broken pixmap.

comment:3 Changed 10 years ago by Github

Milestone: unknown0.25
Resolution: fixed
Status: newclosed

Fixed preview generation (at least for my case)

Fixes #9904

This was a death by many papercuts 1) seeking to the end of file seems to miss the last entry in the recordedseek

table. I left this as is.

2) seeking to the end of file does a linear search to find the frame. The one

thing I changed here was to make it actually fast-forward to the last known frame position before starting the search. In the preview case, it was doing a linear search from frame 0 to the last frame in the file, which took longer than the timeout period. This fixed the timeouts by jumping as far as we can first.

3) we were seeking to the end of the file due to a uint64 overflow caused by

doing an unqualified "frame - 1" even if frame was 0. The MAX_UINT64 value was then capped to the last frame number pre-seek. I changed this to only subtract 1 if the value wasn't 0, and to use 0 if it was 0.

4) we were asking for position 0 as the logic in the previewgenerator told it

to. if the value was 0 (which it always is on remote previews!), the code fell through to ask for frame 0 (which then got buggered by the above problems). I changed the logic such that it would instead seek to 1/3 into the program as we originally desired.

Caveat: I do not yet know how this will act with a recording in progress, however we do rebuild a preview (AFAIK) when the show finishes recording.

I also don't know how the code changed such that this started happening, but whatever. It seems to be fixed again.

Branch: master Changeset: 57b2cddc4d52a4231e1d441b510131e4090e68d9

Note: See TracTickets for help on using tickets.