Hi everyone,
relative noob here :)

Just an observation I thought I'd share.

I have a TSU9600 with RFX9400 extender, controlling Samsung 46" LCD TV, Pioneer AVX2 receiver, Panasonic STB/PVR/DVD recorder and Windows MCE games machine.

I recently thought of having a go at the PoR (picture on remote). After hunting around my (seemingly) bottomless pit of odds-and-ends, I found an Hirschmann RVIP-T video IP tranmitter/receiver. oh, goody! that saves me a few $$. it also has a programmable 'transparent' RS-232 port that can be addressed from the IP end to send/receive code.

So I hooked it up to the network, used the serial cable to set the IP address, etc.

all good. Then I connected the browser (Netscape I still use is reliable), with the standard "http://RVIP.simonnet.net.au/snap.jpg" request, and I got a picture!!
too easy!, so I quickly cobbled together a PS to do the same thing, and it gave me a blank picture. So I frowned.

to cut a really long (3 weeks) story short, I grabbed an image in the browser, saved it to the hard drive, then manually inserted it into the PEPv2 xcf, and it worked fine.
Curiouser and curiouser I thought. In the end I determined that the RVIP-T was inserting an errant JPG header, with incorrect length tag.

I modified my PS to remove the bytes of the offending header. As the RVIP always gives the same header size, just the 6 bytes needed to be removed from each frame captured.

Now to the question - what does PEP do to an image when it is placed in the XCF, compared to retrieving the image directly from the IP source?

or

Is there a bug in the code of the Pronto firmware which fails to ignore "errant" JPG header codes? the JPg spec says it should be ignored, and browsers (and PEPv2) correctly ignore the bad header tag.

Thanks

Simon

If you were to open up an XCF in winzip, you would see ONLY 2 types of image files. .bmp and .png. The native graphic engine of the pro remotes is .png. Any .jpg files you insert into the editor are converted to 24 bit .bmp files when saving your XCF.

I suspect that the webserver is delivering a 'chunked' http header in the middle of your data, especially if the file is large. The Philips RSS feed example on their website (u can download if you are level 1 certified) deals with chunked headers if you are wanting to have a look at the code.

I could be wrong but and if so, with regard to a bug or not? After investigating whether or not you are dealing with a 'chunked' file, and you still have an issue, why not ask belgium? Send your email to prontoteam at philips dot com and include link to image or attach the one you are having problems with.

Hi Lyndel,
Thanks for the info on XCF image handling. Interesing.

The captured image from the RVIP is sent in 3 or 4 packets, but is reassembled correctly in the pronto. I have verified that the jpg image has (perhaps purposely) a bad JPG header - the one I save from the browser has the same code issue.

It's not really a problem - as I said, I have added a line in the code to remove the bad header from each captured frame. with the bad header gone, it all works fine - I can read the program guide and set record timers,etc without turning the telly on.

I think I just wanted clarification on the PEP behaviour, and to point out that some video transmitters send bad code in the captured data.

If you have a file with the bad header, you might want to forward it via email to belgium. It could be that the image library they use does not support it. I doubt they will provide a direct fix but if the library they use has a newer version, they might include it in a future firmware update.