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)

mythtv-mythxml-wo-upnp.patch (869 bytes) - added by geoffrey.antos@… 16 years ago.
Patch to enable always enable MythXML, regardless of whether UPnP will be used.

Download all attachments as: .zip

Change History (31)

comment:1 Changed 17 years ago by xris

Resolution: worksforme
Status: newclosed

Works fine for me. Haven't had any issues like this since before .20.

comment:2 Changed 17 years ago by xris

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 goldwein@…

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 xris

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 anonymous

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 anonymous

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 anonymous

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 mythtv@…

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 anonymous

Resolution: worksforme
Status: closedreopened

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 stuartm

Component: mythwebupnp
Owner: changed from xris to stuartm
Status: reopenednew

comment:11 Changed 16 years ago by anonymous

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 Joe Ripley <vitaminjoe@…>

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 Changed 16 years ago by 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.

comment:14 Changed 16 years ago by Joe Ripley <vitaminjoe@…>

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 in reply to:  13 Changed 16 years ago by Joe Ripley <vitaminjoe@…>

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 Changed 16 years ago by anonymous

I haven't been able to get the wget to work correctly. I don't think I am requesting the right URL.

comment:17 in reply to:  16 Changed 16 years ago by Joe Ripley <vitaminjoe@…>

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 stuartm

Status: newaccepted

comment:19 Changed 16 years ago by stuartm

Resolution: fixed
Status: acceptedclosed

(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 xris

Resolution: fixed
Status: closednew

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 xris

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 stuartm

Milestone: unknown0.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 anonymous

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 mythtv@…

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 stuartm

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 anonymous

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 dave@…

I'll have opened ticket #4453 for the value too large for defined data type issue..

comment:28 Changed 16 years ago by xris

Priority: minorblocker
Status: newassigned

Changed 16 years ago by geoffrey.antos@…

Patch to enable always enable MythXML, regardless of whether UPnP will be used.

comment:29 Changed 16 years ago by geoffrey.antos@…

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 stuartm

Resolution: fixed
Status: assignedclosed
Ticket locked: set

Geoffrey, I've moved your patch to a new ticket since I'm trying to keep the different preview generation issues separate.

I've created two new tickets, #4668 and #4669 for the outstanding issues which we know about. I'm closing this ticket as the original issue has been fixed.

Note: See TracTickets for help on using tickets.