Panasonic Viera and Transcoding

[jrsd]

Hi,

I successfully got my Panasonic V10 TVset to trigger on-the-fly transcoding. Flv videos automatically get transcoded into avi/divx using ffmpeg. To do this I created a ffmpeg-flv-avi.desc file with appropriate entries. I also added a line to the transcoding.db file with an AVI entry, as well as a line in the clients.db file where I set TR:AVI for the panasonic Viera entry. The transcoding actually works, as I get a correctly transcoded file in the /var/twonkymedia/db/cache directory. If I move this file to my media directory, the TV can read it directly.

My current problem is that the Viera TV does not seem to be able to play cached transcoded files. I wonder whether this is a voluntary limitation imposed by panasonic, or if it is caused by a bug of some sort.

I am running Twonky server 5.1.2, on an OpenSuse linux dist, kernel 2.6. The server is a small 1.8Ghz C7 machine on an EPIA board. TV is hooked up on local 802.3 network.

Here some excerpt of what I get in the Twonky server log, with the file already cached:

Code: Select all

[...]
15:51:24:468 LOG_SCAN: checking for new locations
15:51:24:468 LOG_SCAN filescanner thread checking scan queue
15:51:24:468 dbx_queue_flush flushing cache
15:51:24:468 dbx_queue_flush cache empty
15:51:24:468 LOG_SCAN filescanner thread reading external import items
15:51:24:469 dbx_queue_flush flushing cache
15:51:24:469 dbx_queue_flush cache empty
15:51:24:469 LOG_SCAN filescanner thread checking plugins
15:51:25:469 LOG_SCAN: checking for new locations
15:51:25:469 LOG_SCAN filescanner thread checking scan queue
15:51:25:469 dbx_queue_flush flushing cache
15:51:25:469 dbx_queue_flush cache empty
15:51:25:469 LOG_SCAN filescanner thread reading external import items
15:51:25:470 dbx_queue_flush flushing cache
15:51:25:470 dbx_queue_flush cache empty
15:51:25:470 LOG_SCAN filescanner thread checking plugins
15:51:26:312 HTTP entering receive module
15:51:26:312 LOG_HTTP:HTTP_send_receive GET /cgi-bin/Xffmpeg-flv-avi.desc/DLNA-PNAVI-OP00-CI1-FLAGS01700000/video/O0$3$27I62/Test.avi HTTP/1.1
Host: x.x.x.x:9000
transferMode.dlna.org: Streaming
Connection: keep-alive


15:51:26:312 http_cgi_handler - requested url /cgi-bin/Xffmpeg-flv-avi.desc/DLNA-PNAVI-OP00-CI1-FLAGS01700000/video/O0$3$27I62/Test.avi
15:51:26:313 IsTranscoded - file /var/twonkymedia/db/cache/11Kids2fTest.flv(0x0).avi exists
15:51:26:313 LOG_HTTP:HTTP_send_header HTTP/1.1 200 OK
Content-Type: video/avi
Transfer-Encoding: chunked
Date: Sat, 30 Jan 2010 14:51:26 GMT
Pragma: no-cache
Cache-control: no-cache
Last-Modified: Sat, 30 Jan 2010 14:36:14 GMT
Accept-Ranges: bytes
Connection: keep-alive
transferMode.dlna.org: Streaming
EXT:
Server: Linux/2.x.x, UPnP/1.0, pvConnect UPnP SDK/1.0


15:51:26:347 HTTP entering receive module
15:51:26:347 LOG_HTTP:HTTP_send_receive GET /cgi-bin/Xffmpeg-flv-avi.desc/DLNA-PNAVI-OP00-CI1-FLAGS01700000/video/O0$3$27I62/Test.avi HTTP/1.1
Host: x.x.x.x:9000
Range: bytes=0-
transferMode.dlna.org: Streaming
Connection: keep-alive


15:51:26:347 http_cgi_handler - requested url /cgi-bin/Xffmpeg-flv-avi.desc/DLNA-PNAVI-OP00-CI1-FLAGS01700000/video/O0$3$27I62/Test.avi
15:51:26:348 IsTranscoded - file /var/twonkymedia/db/cache/11Kids2fTest.flv(0x0).avi exists
15:51:26:348 LOG_HTTP:HTTP_send_header HTTP/1.1 406 Not Acceptable
Content-Type: text/html; charset=utf-8
Content-Length: 0
Date: Sat, 30 Jan 2010 14:51:26 GMT
Pragma: no-cache
Cache-control: no-cache
Last-Modified: Sat, 30 Jan 2010 14:36:14 GMT
Accept-Ranges: bytes
Connection: keep-alive
transferMode.dlna.org: Streaming
EXT:
Server: Linux/2.x.x, UPnP/1.0, pvConnect UPnP SDK/1.0


15:51:26:367 HTTP entering receive module
15:51:26:368 LOG_HTTP:HTTP_send_receive GET /cgi-bin/Xffmpeg-flv-avi.desc/DLNA-PNAVI-OP00-CI1-FLAGS01700000/video/O0$3$27I62/Test.avi HTTP/1.1
Host: x.x.x.x:9000
transferMode.dlna.org: Streaming
Connection: keep-alive


15:51:26:368 http_cgi_handler - requested url /cgi-bin/Xffmpeg-flv-avi.desc/DLNA-PNAVI-OP00-CI1-FLAGS01700000/video/O0$3$27I62/Test.avi
15:51:26:368 IsTranscoded - file /var/twonkymedia/db/cache/11Kids2fTest.flv(0x0).avi exists
15:51:26:368 LOG_HTTP:HTTP_send_header HTTP/1.1 200 OK
Content-Type: video/avi
Transfer-Encoding: chunked
Date: Sat, 30 Jan 2010 14:51:26 GMT
Pragma: no-cache
Cache-control: no-cache
Last-Modified: Sat, 30 Jan 2010 14:36:14 GMT
Accept-Ranges: bytes
Connection: keep-alive
transferMode.dlna.org: Streaming
EXT:
Server: Linux/2.x.x, UPnP/1.0, pvConnect UPnP SDK/1.0
[...]

Note: I replaced my DSL IP address with x.x.x.x ; BTW, I wonder why the twonky server is always picking up my external interface and not the intranet interface. Is there a way to configure which interface has to be used/blocked?

Calling http://x.x.x.x:9000/cgi-bin/Xffmpeg-flv ... 2/Test.avi
from a web browser running on the same network segment than the tv plays the video fine.

[Briain]

Note: I replaced my DSL IP address with x.x.x.x ; BTW, I wonder why the twonky server is always picking up my external interface and not the intranet interface. Is there a way to configure which interface has to be used/blocked?

Hi

Similar but different:

Linn Products found that on a ReadyNAS, Twonky 5.0.68 broadcasts both the correct NAS IP address and the NAS loop back address, 127.0.0.1, and that control points were often picking up the incorrect one (I usually had to start my CP, then close and restart it before Twonky library icon appeared)

I found that with 5.1.2, my CP's tended to pick up the correct address first time round so it doesn't seem to be the same as 5.0.68.

I've highlighted this to PV and I believe Linn have very recently tweaked their CP's to prevent this happening with 5.0.

Bri

[jrsd]

Thanks for your answer Briain. Actually, I can force the server to bind to a given interface using the "ip" parameter of the twonkymedia-server.ini file. It's such a pity nobody can tell me to RTFM. I'd be happy to do so instead of posting here.

Back to the Panasonic/Twonky problem, I do not know exactly what is going on. The logs just show twonky is transcoding on the fly and serving the transcoded content fine. The only visible error visible in the log is this "406 error" : LOG_HTTP:HTTP_send_header HTTP/1.1 406 Not Acceptable

Does it have anything to do with the client complaining about not being able to read the data?

It looks to me as if there were some protocol problems between twonky and Panasonic's Viera. Weird enough that Panasonic is giving away twonky licenses with their DLNA TVs, because unless it is intentional, there is definitely something going wrong.

Is there any way I could help the twonky developers to diagnose this problem?

[jondi]

Sorry , sepperate question. I have linked my pc with my Panasonic Tv using Twonky server, Tv finds my Twonky menu and has music, video and photo's, Photo's and video work fine, but Music says " Files not supported " Why is that ? and how do i get them to work ?
Music files are MP3.

[jrsd]

Sorry , sepperate question. I have linked my pc with my Panasonic Tv using Twonky server, Tv finds my Twonky menu and has music, video and photo's, Photo's and video work fine, but Music says " Files not supported " Why is that ? and how do i get them to work ?
Music files are MP3.

Panasonic TVs do not read audio file. I did not try it, but one way might be to "wrap" mp3s in a video with on-the-fly transcoding. You might not completely be OT here, but I start wondering whether the twonky people can help at all.