series2 OSD kind of working, but why does osdwriter fork?

[Fletch319]

Xybyre - First off EXCELLENT work. I know a lot of us on this board have been looking for a solution to the no text2osd problem for a long time. I think you have a great start and are very near a valid solution.


I have been playing around with your ideas for the past few nights. Please let us know if you need any help testing stuff as i'm sure others are eager to get a working solution and are willing to help out in any way we can.

Once you get what you feel is a decent solution it would be awesome if you could post any files/scripts you used to implement it. Although some of us can do the cross compiling ourselves many can not and posting those files would be very helpful also!

Keep up the good work!!!!!

[mmccurdy]

I'm posting the mips files needed to run fly on Tivo series 2. Copying this to your Tivo and adding the appropriate LD_LIBRARY_PATH and regular PATH (for the fly binary) will get you the ability to create a PNG on the fly containing text, or whatever. I suggest moving "fly" to your binary directory for organizational reasons. Easily emulate the functionality of newtext2osd and callerid is at your fingertips.

http://poweredbysarcasm.com/mips/fly.tgz

Be gentle, it's my home website.

Reminder: "osdwrite <pngfilename> -share" will display your fly generated picture. The same command displaying a 1x1 pixel transparent png will return the original display. Don't forget to kill the osdwrite processes afterwards using:
kill `ps x | grep [o]sdwriter | cut -F' ' -f3`
(the [o] in there keeps the grep from being included in the kill list... little unix trick)
(test this without the kill to ensure I posted this from memory correctly. )

Have fun and share advances with Tivo hacks.

-Mark

[TheWickedPriest]

Thanks Mark. A couple of points: "-F" is not recognized as a parameter for "cut"; I think you meant "-d". However, that method fails once more than a thousand processes have been run, since then there's only one leading space. Instead, I suggest taking the first five bytes via "-b". (I'm assuming that the process IDs cycle at 64K, so the field will never be longer than 5 characters; but I'm not sure if that's still true.) The leading spaces are ignored by "kill". (In fact, the whole "cut" command can be ommitted, and it will still work, though it will print error messages for everything after the number.)

Also, the "[o]" trick doesn't work reliably. (In fact, I'm not sure it works at all -- even without it, I sometimes didn't get the grep command in the results, and sometimes did.) What does work is to explicitly filter "grep" back out of the results.

So, my command line looks like this:

kill `ps x|grep osdwriter|grep -v grep|cut -b -5`

There's probably a better way to do it, but the above will always work.

BTW, how about the source for "fly"? Also, I think that package could be cut way down by linking against the standard libc, etc., that are already on the Tivo. Not to mention, what's libX11 doing in there? :-)

[mmccurdy]

I haven't figured out how to staticly compile the libraries into the one fly binary, so from the previous message, I linked to my package of all required libraries. I edited the fly Makefile to suit my needs. If anyone sees a way to trim the library requirements, it will help in the long run.

On the topic of fly, without in-depth research, what's the command to make a truecolor png with an alpha channel. A previous message said this fixed the shadowing.....

I'm going to consider using Imagemagick instead of fly for run-time image manipulation. It's leaps beyond fly, but perhaps that will be why I don't want it. Speed is necessary for OSD's.

Good call on the kill command. I am so used to grep or killall that I hadn't used cut much.

http://poweredbysarcasm.com/mips/fly-2.0.0-mips.tgz

Mark

[TheWickedPriest]

I tried osdwriting some non-fullscreen images, with interesting results: The image appeared twice, once in the upper left corner and once exactly centered onscreen. Then, when I went back to a menu, it appeared both in its normal location and in the window where the centered image had been. Presumably the same thing is happenning with 720x480 images -- and I can sometimes see them being drawn, and then jumping sideways a little -- which makes me wonder if 720x480 isn't quite the maximum size. I haven't tested that yet (nor have I tried transparent images), though I did try some much larger images, which weren't displayed, and just made the Tivo hang for a few seconds.

[ronnythunder]

maybe i'm offbase here, but wouldn't it seem that osdwriter would be a fairly simple piece of code that could be substantially reverse engineered with strace and/or some disassembly? that might let us come up with a custom writer that we can control.

ronny

[Fletch319]

First off disassembly is never easy. I have already done so. From my observations this program is only designed to display images so there doesn't seem to be any other way of controlling it to display what we want (besides what has been accomplished here so far).

The only real way to display text only would be to figure out how tivoapp does it and use that. But that will not be easy.

As I see it we almost have a viable caller id solution here. If YAC or elseed were modified to simply pipe text to a script that would call FLY (which would generate the png) then osdwriter to display the png/clear it then the script could kill the processes.

Of course all of this could be compiled into a new sort of text2osd for series2 but unfortunately that is a bit beyond my abilities at this point.

Feedback??

[ronnythunder]

what i meant was: write our own so we can get rid of this forking buisness. it'd still just display pngs, i.e. the base function wouldn't change.

great work so far, though, guys...

ronny

[Fletch319]

it would definately be possible but it seems like a lot more work than to just use the kill command with grep. Although an application without that problem would be better it may not be worth the effort.

[Xybyre]

hey, it's great to see I'm not the only one working on this!

To create a truecolor image with an alpha channel, use gdImageCreateTrueColor(), then call gdImageSaveAlpha(img, 1). This fixes any display problems with osdwriter.

The only libraries needed by fly should be libfreetype.so.6, libgd.so.2, libjpeg.so.62, libpng.so.3, libpng12.so.0.1.2.5. That's what they are for mine, anyway (plus, this is from memory, so I could have missed something). Of course, libfreetype & libjpeg are not needed if you didn't build it into gdlib.

I also noticed a performance problem with using shell scripts & fly. I don't get the caller-id display until almost the third ring. I wrote a stand-alone program that uses gdlib to create my caller-id box, and it seems a little faster.

However, my yac client only receives a message for the first call. Subsequent calls aren't received. This is with the yac client from sunflowerhead.com. I verified this using 'yac -D' and the Yac listener test dialog on the Yac server. I didn't change any of the source code. Anybody else seeing this problem? If I restart yac, it will receive [only] the next call again.

[mmccurdy]

My goal for myself is to roll all these libraries into fly itself staticly with altered code to make system calls to thereby emulate newtext2osd. Xybyre brought up a good point on how speed is of the essence. If this app only gets the data after the first ring, it may take an extra ring (or two) to display the message. By then, I can reach for my callerid phone...

[Xybyre]

Keep in mind that staticly-linked programs take up a lot of memory and disk space. A static fly is around 2 MB (4MB if you include libc & libm), versus a dynamic one at 56 KB. It may make sense if you use rarely-used libraries that most people don't already have. However, they will take up much more memory, which the TiVo doesn't have much of. The TiVo would probably benefit from using shared libraries where possible, although I do understand your desire for an independent executable.

btw, I patched the yac client to work on my HDVR2. Apparently, it doesn't like it when the client shuts down the server socket and creates another one right away. I just re-used the same server socket instead of closing it and reopening it. dunno if anybody else is having this problem...

Now that everything is working for me, I will clean up the code and do a little more testing before I make it available to all.

[zooloo]

Nice to see stuff happening with OSD, i put this aside awhile ago after getting limited responses to my original post on the subject back in June -

http://www.dealdatabase.com/forum/sh...threadid=24865

and mainly because I was having some nasty memory problems, probably due to memory defrag, when running a number of the osdwriters followed by kills.

I noticed that sometimes memory would be allocated by osdwriter, and after the kills it wouldn't all be freed, eventually it would crash my hdvr2 with a nasty white-noise audio output.

Has anyone run into this yet?

-zooloo

[mmccurdy]

I tested altering the image from 720x480 to something smaller that didn't create the shadow. The answer is 708x480. Here's my bash script that outputs the OSD using fly. No alpha channels, no truecolor needed. Fast enough to respond to callerid data.

It's not emulating newtext2osd yet, but here are the files that will get you goin. I've included as comments the true series1 file's arguments that will need to be emulated.

New bash shell script:
http://poweredbysarcasm.com/mips/newtext2osd

Repost:
5MB
http://poweredbysarcasm.com/mips/mips.tgz

160KB
http://poweredbysarcasm.com/mips/fly-2.0.0-mips.tgz

[embeem]

1st: whoever keeps bitching about the screen module, knock it off; the screen module takes the text from the tivo screen and translates it into hyperlinks, nothing more and far from perfect. (try it sometime the tivo itself is in a menu)

2nd: using a png and osdwriter is kludge

Yeah it's cute and all, but time is far better spent reverse engineering the actual OSD than tweaking pngs.

That said, OSD on the series2 is quite different than that of the series1 and looks to be quite the pain in the ass. Access to the OSD is through the /dev/bcmgfx device, there are are a dozen or so different ioctl comands which need to be mapped out {AllocateSurface, InitSurface, CreateSubSurface. Display, unDisplay ... } -- in a word Ugh.