On 5/1/06, <b class="gmail_sendername">Andrew Kuan</b> <<a href="mailto:askuan@gmail.com">askuan@gmail.com</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div style="direction: ltr;">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 <span style="font-style: italic;">owned by root</span>. 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.</div></blockquote><div><br>
Hi Andrew,<br>
<br>
Thanks for the info. I tried to change the owner of the png files in my
recordings folder to apache:apache (I guess that the user that MythWeb
runs as). 13 of the PNGs in the recordings folder were then recreated
when MythWeb reloaded. But the usual 418 PNGs in
mythweb/data/cache were still updated. I have checked a couple of
updated PNGs from the recording folder. The same PNGs are also updated
in the mythweb folder.<br>
The start of the recordings page now appears within 22 seconds and the
whole list is ready after 102 seconds. This is an improvement and
probably as good as 0.18.1 was. But it should not be necessary to
regenerate so many PNGs each time. So I will probably try your other
suggestions.<br>
<br>
Best regards<br>
Niels Dybdahl<br>
</div></div><br>