Modify
Warning Please read the Ticket HowTo before creating or commenting on a ticket. Failure to do so may cause your ticket to be rejected or result in a slower response.

Opened 7 years ago

Closed 6 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@… 6 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 7 years ago by xris

  • Resolution set to worksforme
  • Status changed from new to closed

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

comment:2 Changed 7 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 7 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 7 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 7 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 7 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 7 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 7 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 6 years ago by anonymous

  • Resolution worksforme deleted
  • Status changed from closed to 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 6 years ago by stuartm

  • Component changed from mythweb to upnp
  • Owner changed from xris to stuartm
  • Status changed from reopened to new

comment:11 Changed 6 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 6 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 follow-up: Changed 6 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 6 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 6 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 follow-up: Changed 6 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 6 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 6 years ago by stuartm

  • Status changed from new to accepted

comment:19 Changed 6 years ago by stuartm

  • Resolution set to fixed
  • Status changed from accepted to 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 6 years ago by xris

  • Resolution fixed deleted
  • Status changed from closed to 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 6 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 6 years ago by stuartm

  • Milestone changed from unknown to 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 6 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 6 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 6 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 6 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 6 years ago by dave@…

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

comment:28 Changed 6 years ago by xris

  • Priority changed from minor to blocker
  • Status changed from new to assigned

Changed 6 years ago by geoffrey.antos@…

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

comment:29 Changed 6 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 6 years ago by stuartm

  • Resolution set to fixed
  • Status changed from assigned to closed
  • 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.

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'new'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.