Twonky Forum

The config:
Twonkyserver 6.0.28 on Ubuntu 10.10, serving up video, images and music from local drives
ffmpeg installed from Ubuntu repos
The videos on the machine are a mix of MPEG-1 (.mpg), DIVX and WMV

Samsung Galaxy S running official Samsung Android 2.2 firmware.
The Galaxy S supports WMV, DIVX and MPEG-4 video

The problem:
The WMV and DIVX files work fine
The MPG files do not get transcoded to MPEG-4 (or WMV)

The logs:
When BROWSING the media server, the phone uses the samsung app "Allshare" which sends a USER-AGENT
string of:

SEC_HHP_Galaxy S/1.0

When attempting to play a file, however, Allshare hands off the file's URL to the Samsung media player which sends
a USER-AGENT string of:

Samsung Player User-Agent

When playing, it ALSO, stupidly, the player sends an Accept header of */* (which is patently untrue!)

Now, SOMEHOW yesterday I DID get TS to attempt an MPEG->MPEG-4 transcode - only to find that ffmpeg fails
this type of encoding due to the decision of the Ubuntu guys to deliver ffmpeg WITHOUT libfaac support (and the internal
aac converter doesn't work either). I don't know how I managed it, and in reorganizing things a bit today it no longer attempts the transcode - it is asked for, and sends, the original mpg file.

SO - How do I get Twonky to recognize that the Samsung player is lying, that it does NOT support every possible format, and thus to make it transcode these MPG files to WMV (since MPEG-4 transcoding doesn't work) on the fly (the alternative, of course is to convert my entire video library to WMV - but frankly I shouldn't need to!!)?

In fading hope of a quick response (I've seen many similar requests on this forum go completely unanswered by the experts out there).

P.s. I have tried entries in the client DB for both strings that look like this:


NA:Samsung Galaxy S
HH:SEC_HHP_Galaxy S/1.0
XM:DLNA15
TR:JPEG120x90,JPEG1920x1080,MP3,WAV,WMV
DB:FIX

and

>>
NA:Samsung Player User-Agent
HH:Samsung Player User-Agent
XM:DLNA15
TR:JPEG120x90,JPEG1920x1080,MP3,WAV,WMV
DB:FIX

TS recognizes these (they appear in the receivers list on the config console) but no transcoding takes place.

Partial success:

Having just the "Samsung Galaxy" entry, but adding

MT:mpg not-supported

causes the transcoding to take place!! BUT if the file is too big, TS sends back these headers:

HTTP/1.1 206 Partial Content
Content-Type: video/x-ms-wmv
Content-Length: 9999999999999999
Date: Mon, 03 Jan 2011 17:43:35 GMT
Pragma: no-cache
Cache-control: no-cache
Last-Modified: Mon, 03 Jan 2011 17:43:35 GMT
Accept-Ranges: bytes
Connection: close
Content-Range: bytes 0-9999999999999998/9999999999999999

Which is patently not true - since the transcoding is still in progress at this point.

The client then does this (eventually - it manages to get some of the initial data correctly):

GET <my file url>.wmv HTTP/1.1
Accept: */*
Host: 192.168.1.102:9000
Range: bytes=807829504-808091647
x-wap-profile:
User-Agent: Samsung Player User-Agent
Connection: Keep-Alive

To which the server responds:

HTTP/1.1 416 Requested Range Not Satisfiable
Content-Type: text/html; charset=utf-8
Content-Length: 0
Date: Mon, 03 Jan 2011 17:43:36 GMT
Pragma: no-cache
Cache-control: no-cache
Last-Modified: Mon, 03 Jan 2011 17:43:36 GMT
Accept-Ranges: bytes

And that results in an error on the device.

Now, I realize that transcoding large files on the fly isn't a great idea, but I wonder if there is a better way to handle this in the device config?

BUT things are looking better!