[mythtv-users] Viewing recorded programs page in mythweb is slow
askuan at gmail.com
Mon May 1 12:31:01 UTC 2006
I think I just solved my problem. Pretty silly really. In the
generate_preview_pixmap function, the modification timestamp of the
thumbnail file in /var/video is compared against the modification timestamp
for the recording in the database (as Niels already noted). Well for the
nine files that were causing problems for me, the .png files were owned by
root. So in all likelihood, mythbackend probably tried to recreate the png
and overwrite the old copy, but repeatedly failed to do that because the old
file was in the way. As soon as I chowned the file to mythtv, they got
overwritten in /var/video at the reload of the Recorded Programs page
(taking the usual lengthy amount of time). Reloading again, after the png
files were updated in /var/video, took only a few seconds.
On 5/1/06, Andrew Kuan <askuan at gmail.com> wrote:
> So I did a bit of experimenting as well. I altered two files in my copy of
> mythweb from the end of the 0.19-fixes branch:
> - I commented out line 207 in modules/tv/recorded.php so that
> "generate_preview_pixmap" wouldn't get called.
> - I hacked up themes/default/tv/recorded.php so that it looks
> directly in my /var/video directory for thumbnails rather than checking its
> own cache. I then had to make sure that Apache could follow a symlink off to
> where those thumbnails (and all of my recordings) are stored.
> After I made these two changes, the Recorded Programs page was suddenly
> loading in a couple seconds with all of the thumbnails showing -- except for
> shows that are currently being recorded.
> While this solves it well enough for me, I do still have a few misgivings:
> 1. No thumbnail will be available for shows currently being
> 2. I don't like having my /var/video directory exposed to the rest
> of the world -- which is probably why the cache was set up in the first
> 3. The next time I update mythweb, I'm going to have to rehack my
> files to keep things chugging along.
> It looks like the real solution would be to fix the
> generate_preview_pixmap function in the first place. It's in
> includes/mythbackend.php at line 226. I'm going to poke at it for a bit
> right now before I head off to work. Thanks for the feedback, Niels -- it's
> sort of reassuring to know that someone else is putting up with this
> behavior too.
> On 5/1/06, Niels Dybdahl <Niels at dybdahl.dk> wrote:
> > > b) looking at the timestamps, a handful of .png files (nine to be
> > exact) keep getting re-created everytime I view the Recorded Programs
> > page of mythweb.
> Mythweb checks the modification timestamp for the recording in the
> database and compares it with the creation date of the thumbnail. If
> the thumbnail is too old, it requests a new one from the backend. This
> means that either your database is somehow corrupt and has timestamps
> set in the future, or you're changing (that include playing) the
> I have the same problem, so I checked in my mythweb/data/cache folder.
> I opened the recorded shows in MythWeb and 439 out of 528 thumbnails were
> A couple of minutes later I refreshed the web page and this time 418
> thumbnails were regenerated. I could not watch so many shows in such a short
> time and I do not think that all these entries should be corrupt. None of
> them have dates in the future.
> I just tried once more and all 418 thumbnails from second try were
> regenerated, so the 21 (439-418) that were not regenerated in the second and
> third try could have been played or new since last time I used MythWeb.
> The 418 shows consists of all recorded with 0.18.1 and numerous recorded
> with 0.19 including those recorded today.
> Niels Dybdahl
> mythtv-users mailing list
> mythtv-users at mythtv.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the mythtv-users