bizzy
06-01-2008, 11:56 AM
Hey folks, I was goofing around with the stock (not TivoWeb) web interface the S3/HD runs at https://tivo/nowplaying/. I noticed that the HTML returned includes a reference to 'images/high-definition-folder.png' for the "HD Recordings" pseudo-folder. Unfortunately, on my 9.3 S3, that request returns a 404 'Resource not found'.
Since I am running the interface through Apache's mod_proxy anyway, I defined a filter that just replaces 'high-definition-folder.png' with 'folder.png'; but I was wondering if any of you with shell access into the device could check and see if:
* there actually _is_ a special image for the HD folder
* if so, what the correct filename is
Additionally, if anyone's interested, I can post my proxy config. I had to use a couple of tricks that took me a while to figure out:
* need to proxy both http and https for the device - some content is available via http, and some via https, but there doesnt seem to be overlap, which mainly seems to be a way for them to avoid serving video files via https, which is probably too processor-intensive
* to support the http/https seperation, the web interface returns absolute URLs including hostname:port, which you need to filter if you're proxying.
* the embedded web server doesn't like http 1.1 proxies or keep-alives, and will return 5xx service unavailable randomly until you stick to http 1.0.
anyway, if you have a moment to peek, that would be keen.
thanks!
matto
Since I am running the interface through Apache's mod_proxy anyway, I defined a filter that just replaces 'high-definition-folder.png' with 'folder.png'; but I was wondering if any of you with shell access into the device could check and see if:
* there actually _is_ a special image for the HD folder
* if so, what the correct filename is
Additionally, if anyone's interested, I can post my proxy config. I had to use a couple of tricks that took me a while to figure out:
* need to proxy both http and https for the device - some content is available via http, and some via https, but there doesnt seem to be overlap, which mainly seems to be a way for them to avoid serving video files via https, which is probably too processor-intensive
* to support the http/https seperation, the web interface returns absolute URLs including hostname:port, which you need to filter if you're proxying.
* the embedded web server doesn't like http 1.1 proxies or keep-alives, and will return 5xx service unavailable randomly until you stick to http 1.0.
anyway, if you have a moment to peek, that would be keen.
thanks!
matto