Opened 17 years ago
Closed 16 years ago
#3217 closed defect (fixed)
Mythweb writes 0 size png thumbnails files in data/cache directory
Reported by: | anonymous | Owned by: | stuartm |
---|---|---|---|
Priority: | blocker | Milestone: | 0.21 |
Component: | upnp | Version: | head |
Severity: | low | Keywords: | mythweb png thumbnails |
Cc: | Ticket locked: | yes |
Description
When displaying recorded programs in mythweb, thumbnails that are generated are 0 size files. No errors show in the backend log, and this happens even when the data/cache directory is world writable.
Attachments (1)
Change History (31)
comment:1 Changed 17 years ago by
Resolution: | → worksforme |
---|---|
Status: | new → closed |
comment:2 Changed 17 years ago by
fyi, you might want to make sure that you have upnp enabled on the backend, since mythweb uses these methods to access the preview pixmaps.
comment:3 Changed 17 years ago by
Would it help if I told you that the zero size images being transferred to the mythweb data/cache directory are of the format "1008_20060508210000.mpg.100x0x64.png" while the original displayable png files located in the recordings directory are in the form "1008_20060508210000.mpg.png". It seems like mythweb is requesting a preview pixmap be genereated that is 100x0 (width x height), 64 seconds into the recording. Maybe it is the 0 height that is the problem? Not sure how I can change that in any setting, but the original png files display fine on the MythTV recordings listing.
Thanks
JG
comment:4 Changed 17 years ago by
The zero is fine. Just means "pick the appropriate height for the aspect ratio". You really need to make sure that upnp is enabled in your backend.
comment:5 Changed 17 years ago by
I have been experiencing the same problem for a while now. Below is from SVN 13187 (I updated both mythtv and mythplugins a few hours ago).
Changing line 300 of modules/tv/tmpl/default/recorded.php from
><img src="<?php echo $show->thumb_url(100,0) ?>"></a>
to
><img src="<?php echo $show->thumb_url(160,120) ?>"></a>
prevents the problem.
From the above comment by Xris, it would appear something is going wrong with the "pick the appropriate height for the aspect ratio" code. Forcing the size makes it all work.
comment:6 Changed 17 years ago by
If anyone else hits this issue, I found it was caused by having allow_url_fopen disable d in php.ini. Setting it to On fixed the issue.
comment:7 Changed 17 years ago by
I've been struggling with this for months, and tried numerous times to figure out how to turn on UPNP, always coming to the conclusion that it should be turned on by default. It turn out that the above mentioned change to recorded.php fixes the problem for me as well.
I believe there's a bug somewhere, and constantly asserting that it's a UPNP issue is counter productive. Especially since there appears to be no way to turn it on (just an option to turn it off)...
Thanks for the help anonymous!
comment:8 Changed 17 years ago by
Changing that line:
<img src="<?php echo $show->thumb_url(160,120) ?>"></a>
Also fixes the problem for me.
Does this mean it is going to make it into SVN at some point? Or is this issue considered dead?
comment:9 Changed 16 years ago by
Resolution: | worksforme |
---|---|
Status: | closed → reopened |
This issue still exists in the current trunk.
I still patch in the 160,120 work around mentioned above at each update.
comment:10 Changed 16 years ago by
Component: | mythweb → upnp |
---|---|
Owner: | changed from xris to stuartm |
Status: | reopened → new |
comment:11 Changed 16 years ago by
For me, setting allow_url_fopen = On worked for 3 thumbnails, while the patch worked for the remaining 155 recordings. Thanks so much!
comment:12 Changed 16 years ago by
I am experiencing this problem as well. I believe I've tracked it down to this log entry from mythbackend:
2007-12-04 22:11:09.169 MediaServer:: Bad BackendServerIP Address - 127.0.0.1. Disabling UPnP
I have a single machine (combined FE/BE). Both of the IP addresses in mythtv-setup are set to 127.0.0.1. This seems to disable uPNP (ala programs/mythbackend/mediaserver.cpp line 73).
Perhaps this is part of the problem discussed in this ticket?
-- Joe Ripley vitaminjoe@…
comment:13 follow-up: 15 Changed 16 years ago by
I don't have the above log message regarding upnp. I have a backend with multiple frontends - my ip addresses in mythtv-setup are the correct ip address of the backend and not loopback.
comment:14 Changed 16 years ago by
Since I use 127.0.0.1 as my backend IP address, I commented out the code in mediaserver.cpp:
Index: mediaserver.cpp =================================================================== --- mediaserver.cpp (revision 15058) +++ mediaserver.cpp (working copy) @@ -68,12 +68,12 @@ m_pHttpServer->m_sSharePath = m_sSharePath; - if (sIP == "localhost" || sIP == "127.0.0.1") - { - VERBOSE(VB_IMPORTANT, "MediaServer:: Bad BackendServerIP Address - " - + sIP + ". Disabling UPnP"); - return; - } +// if (sIP == "localhost" || sIP == "127.0.0.1") +// { +// VERBOSE(VB_IMPORTANT, "MediaServer:: Bad BackendServerIP Address - " +// + sIP + ". Disabling UPnP"); +// return; +// } if (bDisableUPnp) {
This fixed the problem with MythWeb's preview pixmap generation code (for me). The code above disables UPnP when using the loopback IP as the backend IP. MythWeb relies on the UPnP code to generate preview pixmaps. Commenting it out makes everything work again.
Is there a good reason to disable UPnP when using the loopback IP? (nigel implemented this in changeset [14889]).
-- Joe Ripley vitaminjoe@…
comment:15 Changed 16 years ago by
Replying to anonymous:
I don't have the above log message regarding upnp. I have a backend with multiple frontends - my ip addresses in mythtv-setup are the correct ip address of the backend and not loopback.
What version of mythbackend are you running (mythbackend --version)? The code that allows mythweb to ask for preview pixmaps was finalized (I believe) in changesets [13022] and [13208]. Anything older probably won't work.
You can test the output of the UPnP pixmap request with wget. Do something like this:
wget 'http://127.0.0.1:6544/Myth/GetPreviewImage?ChanId=1054&StartTime=2007-08-19T12:00:00&Height=0&Width=100&SecsIn=79/data/cache/1054_20070819120000.mpg.100x0x79.png'
This is how MythWeb gets its pixmap previews. It does a file_get_contents() call on line 565 (or thereabouts) in modules/tv/includes/objects/Program.php.
I had to patch my mythbackend to allow UPnP on 127.0.0.1 to get this working again.
-- Joe Ripley vitaminjoe@…
comment:16 follow-up: 17 Changed 16 years ago by
I haven't been able to get the wget to work correctly. I don't think I am requesting the right URL.
comment:17 Changed 16 years ago by
Replying to anonymous:
I haven't been able to get the wget to work correctly. I don't think I am requesting the right URL.
I probably quoted it wrong. The URL format is as such:
http://<hostname>:6544/GetPreviewImage?ChanId?=<chanid>&StartTime?=YYYY-MM-DDTHH:MM:SS&Height=0&Width=100&SecsIn=79
Using wget:
wget 'http://127.0.0.1:6544/Myth/GetPreviewImage?ChanId=1054&StartTime=2007-08-19T12:00:00&Height=0&Width=100&SecsIn=79' -O file.png
This will connect to 127.0.0.1:6544 and save the preview image from the recording made from ChanID 1054 on 2007-08-19 @ 12:00:00 to a file called 'file.png'.
If you get a zero byte file, check your mythbackend logs for errors. It usually means that UPnP is disabled or there was a problem reading the source video file.
-- Joe Ripley vitaminjoe@…
comment:18 Changed 16 years ago by
Status: | new → accepted |
---|
comment:19 Changed 16 years ago by
Resolution: | → fixed |
---|---|
Status: | accepted → closed |
(In [15328]) This slightly convoluted change to the http/xml GetPreviewImage? function attempts to speed up preview generation for mythweb and support for preserving the aspect ratio of a rescaled preview image.
First, if a default preview image exists then rescale that to the required size instead of generating a new one from the video. This is several seconds faster on my backend for just a single image.
Second, if you supply a Height but no Width, or a Width but no Height, then scale the image to that dimension whilst preserving aspect ratio.
The PreviewPixmapOffset? is now honoured if SecsIn? is not defined or is equal to zero. If you supply a SecsIn? argument > 0 or "!= PreviewPixmapOffset?" then a new image will be generated.
There is a change to the filename format. Old: filename.WxHxS.png New: filename.S{.WxH}.png
Closes #3217
comment:20 Changed 16 years ago by
Resolution: | fixed |
---|---|
Status: | closed → new |
No good, sorry...
fyi, I'm pretty sure that the zero-byte pixmaps in mythweb happen when it times out trying to get data from the backend (because the backend is overloaded trying to generate the requested pixmaps)
comment:21 Changed 16 years ago by
It does seem to be a little better about things, though.. but eventually goes and ends up eating up 400% of my cpu and hanging there (quad core)
comment:22 Changed 16 years ago by
Milestone: | unknown → 0.21 |
---|
We are definitely looking at more than one cause of zero-byte images, [15328] just fixed the one originally reported in this ticket. Subsequent changes to the way preview generation works seem to be causing another.
comment:23 Changed 16 years ago by
Here's what I get when I use wget against my slave backend (which has the recordings in question):
2008-01-06 09:34:31.687 Using runtime prefix = /usr/local 2008-01-06 09:34:31.707 Empty LocalHostName. 2008-01-06 09:34:31.708 Using localhost value of proteus 2008-01-06 09:34:31.713 Testing network connectivity to mars 2008-01-06 09:34:31.976 New DB connection, total: 1 2008-01-06 09:34:32.032 Connected to database 'mythconverg' at host: mars 2008-01-06 09:34:32.042 Closing DB connection named 'DBManager0' 2008-01-06 09:34:32.045 Connected to database 'mythconverg' at host: mars 2008-01-06 09:34:32.048 Current Schema Version: 1205 2008-01-06 09:34:32.053 New DB connection, total: 2 2008-01-06 09:34:32.056 Connected to database 'mythconverg' at host: mars 2008-01-06 09:34:32.663 AFD: Opened codec 0x829e0b0, id(MPEG2VIDEO) type(Video) 2008-01-06 09:34:32.667 AFD: Opened codec 0x829e530, id(MP2) type(Audio) 2008-01-06 09:34:33.278 Preview: Grabbed preview '/mythtv/recordings/2170_20071228100000.mpg' 720x480@79s 2008-01-06 09:34:33.559 HTTPRequest::SendResponse( File ) :200 OK -> 192.168.1.39: 2008-01-06 09:34:33.559 SendResponseFile ( /mythtv/recordings/2170_20071228100000.mpg.100x0x79.png ) 2008-01-06 09:34:33.563 SendResponseFile( /mythtv/recordings/2170_20071228100000.mpg.100x0x79.png ) Error: 75 [Value too large for defined data type] 2008-01-06 09:34:33.566 HttpWorkerThread::ProcessWork socket(27) - Error returned from SendResponse... Closing connection 2008-01-06 09:34:34.571 MythXML::ProcessRequest: GetPreviewImage : GET /Myth/GetPreviewImage?ChanId=2170&StartTime=2007-12-28T10:00:00&Height=0&Width=100&SecsIn=79 HTTP/1.0
This is with -v upnp on, and running wget as follows:
wget 'http://192.168.1.48:6544/Myth/GetPreviewImage?ChanId=2170&StartTime=2007-12-28T10:00:00&Height=0&Width=100&SecsIn=79' -O file.png
Same behavior happens if I specify the width as 160 and height as 100. The previews are getting made, they're just not getting transferred over to mythweb.
I know I'm not running the latest SVN (I'm running 15290), but hopefully it will help.
comment:24 Changed 16 years ago by
Thanks to everyone who has been working on this bug.
I am now running trunk version 15333. I am still seeing the problem with getting the icons in mythweb. The 160,120 patch above continues to resolve the issue.
comment:25 Changed 16 years ago by
Sorry but I just can't see how it's possible that the 160,120 patch fixes the issue whilst [15328] didn't. Unless you just happen to still have 160x120 sized previews cached in which case of course it will _appear_ to fix the issue. The original problem, where specifying zero for either dimension meant that no icon was returned is definitely solved.
There is at least one other issue related to upnp ([Value too large for defined data type]) and another that seems to be caused by starting a new instance of mythbackend to generate new previews (high cpu usage). I think it would be a good idea to close this ticket again and open new ones for those problems.
comment:26 Changed 16 years ago by
I can't explain it either.
I can remove all the .png files from /data/cache and the recordings directory, view recordings in mythweb, and most shows will have icons. There are still a few with no icons. If I apply the 160,120 patch and refresh, I get icons for all of my shows.
comment:27 Changed 16 years ago by
I'll have opened ticket #4453 for the value too large for defined data type issue..
comment:28 Changed 16 years ago by
Priority: | minor → blocker |
---|---|
Status: | new → assigned |
Changed 16 years ago by
Attachment: | mythtv-mythxml-wo-upnp.patch added |
---|
Patch to enable always enable MythXML, regardless of whether UPnP will be used.
comment:29 Changed 16 years ago by
MythWeb has no need of UPnP functionality, it just needs the backend http server to have a registerd MythXML object. I've uploaded a patch that enables MythXML on the backend's http server regardless of whether UPnP is enabled.
However, if UPnP used, then that same MythXML object is explicitly registered with the Myth UPnP object, yielding the same functionality as before.
comment:30 Changed 16 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Ticket locked: | set |
Works fine for me. Haven't had any issues like this since before .20.