Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#4453 closed defect (invalid)

Mythweb/upnp - zero byte thumbnails, Value too large for defined data type

Reported by: dave@… Owned by: stuartm
Priority: blocker Milestone: 0.21
Component: mythweb Version: head
Severity: medium Keywords:
Cc: Ticket locked: no

Description

In ticket #3217 Stuart asked me to open a separate ticket for this issue. Mythweb is displaying broken links for previews in the recorded programs page. Mythtv is generating the previews properly and putting them in my recordings directory. It then is unable to transfer them correctly to mythweb's data/cache directory, resulting in zero byte files in the data/cache directory. I don't believe it is permissions related. If the backend is run with -v upnp, you can see the "value too large for defined data type" error below. I can also re-create it by using wget to try to grab a preview. It doesn't matter if I specifically specify the size or do the standard 100x0 thing - behavior is the same. I am running svn 15290.

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

Change History (7)

comment:1 Changed 12 years ago by xris

Owner: changed from xris to stuartm
Status: newassigned

comment:2 Changed 12 years ago by xris

Milestone: unknown0.21
Priority: minorblocker

comment:3 Changed 12 years ago by stuartm

Status: assignedstarted

Could you post the the result of:

GET -eUsd http://<backendip>:6544/Myth/GetPreviewImage?ChanId=<chanid>\&StartTime=<timestring>

What filesystem is being used for the recordings? Are they on a network share?

comment:4 Changed 12 years ago by dave@…

I'm not sure how you're asking me to run that.. What do you mean by GET? -eUsd doesn't seem like valid options for wget.

The recordings filesystem is ZFS on Solaris, and they are accessed by my backend servers (one master, one slave) via Samba. Mythweb's data cache is on ext3 on the master.

comment:5 Changed 12 years ago by stuartm

Resolution: invalid
Status: startedclosed

GET is an application similar to wget. I've no idea what packages it ships in, it's usually on every system I've used for the last 15 years.

However it looks like your problem is Samba - cifs is frankly crap and is reporting the wrong filesize to sendfile64(). Samba is frequently the cause of problems I've with mythtv. Have you considered using NFS instead, assuming it's available on Solaris? You can run samba and NFS side by side if you need access to those shares via Windows, but if not then NFS should always be used instead of Samba for sharing between Unix systems.

I'm going to close this as invalid unless you can reproduce the problem using NFS or when the files are accessed locally.

comment:6 Changed 12 years ago by stuartm

FWIW, I quickly googled for sendfile64 + cifs and sendfile64 + samba. Looks like samba can be built with support for sendfile, but I'll let you figure out if that applies or works in your case. I'd still recommend using NFS instead though.

comment:7 Changed 12 years ago by dave@…

Ah, GET is part of libwww-perl. I just switched my recordings directory to NFS and it works now, sorry about the false alarm. I've had much better reliability and performance with Samba than NFS in the past, but it's obviously not going to work here.

Note: See TracTickets for help on using tickets.