DVDSpy confusion...

[Mark F]

I don't have an LCD but your analysis sounds right.

Can you temporarily turn the clock group off to do some further testing of the DVDSpy events and LCDDriver plugin?

[MMcM]

It sounds like you have DVDSpy working properly. And you have LCD working properly. But you have not gotten them connected.

I may well misunderstand, but I think perhaps you are looking for an automatic association between the OSD and the LCD. There isn't one. Having gotten something to work with the OSD plug-in, you can do something similar with the LCD plug-in instead (or in addition -- but separately).

If you have shown that DVDSpy works using the test procedure and have shown that LCD works displaying the time, I suggest starting over from scratch with DVD2LCD.GML and adapting it to your needs. If you have a 4x20 display, it may be close to begin with. (I have a newer version that I shall be releasing shortly that includes weather and/or motherboard info when idle and Winamp3 events.)

There must be something misleading about the readme files that are there now. Perhaps there should be an entirely separate step-by-step how-to file for getting DVDSpy to work with an LCD. Would that be worth it?

The current LCD arrangement is all event-oriented in a piecemeal fashion. Each event puts its payload someplace on the display. This makes it hard to get a good picture of what's going on overall. There is nothing in the overall architecture that would prevent having an alternative means where the event put the state into Girder variables and there was an LCD action for the whole screen. This would just have a stack of four edit boxes into which you typed all the variable names, just like some of the other LCD control programs. There isn't much of an efficiency concern, since the display is already optimized to only output what has changed. It would mean that variable values would need to be padded with spaces (or zeros) to avoid an annoying shuffle as the length of some state changed (or a number went above ten). The current LCD favors fixed width fields for this reason.

I recall posing all this back when the suggestion of moving the standalone DVD -> LCD solution to Girder was introduced. But there was a whole lot less experience with small displays on HTPCs back then. Anyway, do we now think that this new LCD command would be worth it?

Back to your immediate problem, if you are still stuck and/or I misunderstood, feel free to send the GML file you are working with.

[MMcM]

The MediaJukebox.Close event isn't there. I guess it was omitted from the MJ interface. :oops: I'll add it as soon as I get a chance.

The best way to do priorities is to remember the state in variables. That way you can display the previously hidden info right away when you switch to a lower priority screen. Otherwise, you have to wait for a new event for that state, which may never come if it isn't changing (such as the title). This is a lot easier to do with something like the whole screen action I mentioned. I'll see how hard that would be to add.

If you gain some insight into why Close sometimes doesn't clear the VFD, let me know. For instance, does it just lose the event or does the action run but do nothing? I'm leaning toward clearing the display more often than closing it altogether in the revisions I'm making to the samples.

If your VFD (as controlled by LCDriver) does not support hardware marquee, you can simulate it in software by setting a flag in the registry. This is covered in the readme.

[MMcM]

Not only must your display support hardware marquee, but LCDriver must also know that it does. That may be the problem. Do try software mode. I find it flickers too much with an LCD, and so am glad of the supported hardware mode, but with a VFD there may not be any such issue.

The next DVD2OSD.GML has an idle screen which displays variables. It still assumes that each application runs exclusively, so contention remains if more than one is generating events. But it does have some techniques for state maintenance and bulk update that you might be able to use. I can send a pre-release your way if this sounds useful.

[MMcM]

I'm looking at the manual as I add a direct serial alternative to LCDriver. Unless I am completely missing something, Matrix-Orbital VFD displays do not have hardware marquee support, either in the form like Crystalfontz where the firmware shifts periodically, or even in the form of a command to shift a single line by a certain amount. So I think we're stuck with repainting from the host like it does.

[MMcM]

The latest DVDSpy finally has both 2 line (DVD2LCD2) and 4 line (DVD2LCD4) samples. (Actually, the scripts are almost identical; I use XSLT to enable just one of two items when there is a size dependency.) It still assumes that only one player is active at a time. But it has even more variable state and contention resolution logic. So much so that it needs the emerging LUA GVMS implementation. :wink: Once again, it might help suggest ways to do what you want.

[Francois]

Phat,

You should be able to solve your priority (TT/MJ/Clock) issues with a few groups, and a top level 'scanning' group which will enable or disable application groups on TaskCreate/TaskClose events... basically it should operate as follows:


On Taskcreate
is TT open (iswindows or isactive...)?
if so, activate the TT group with its VFD features, keys, etc.
deactivate the other application groups
if not, deactivate TT
is MJ open (windows exists, or isactive)?
if so activate the MJ group
deactivate the other application groups (but TT, to be elegant)

Etc.

I've found this type of architecture to work very well with Girder, a VFD and all my applications (the only tricky thing is to have an event in each application group to track closing reliability to clear the display or write "Closing xxx"... but unless you're using Win9x and TT, the DVDSpy close events work well for many applications)

Another trick that might work in your case is to have a 'default' text for VFD display, that can be superseded by some 'High Priority' message for a limited time. I have done that for instance with the volume control, where I will post on my VFD the volume level for 2 seconds, and then revert the display to its default mode (I have set girder to send a timer event every 1/10th of a second, and adjust a counter, set to 20 initially, until it reaches 0, at which time I change the display). This also allows to have infinite positing of some High Priority information (Mute, etc.) by setting the counter to -1...

[Phat Phreddy]

OK firstly I have read the files and searched the forum... Perhaps I am dense... But for the life of me I am not successful with this...

My VFD is working and LCDDriver can test and control it...

I have followed the DVDSpy installation instructions to the letter...

I have been puzzling my way through the test commands without success..

When I run TT and bring girder to the foreground I can see it detecting an action and prompting an OSD... I enable the OSD pop up and it goes to the screen...

I think I am simply missing whatever steps I ned to do to get the OSD to the LCD ??

[Phat Phreddy]

Forgot to mention... I have Day Date and Time displayed on the VFD now (I did not set this up but it looks like i have a clock event group iun there that keeps reactivating)...

Could this be hogging the display ??

[Phat Phreddy]

OK getting somewhere...

Firstly, Mike thanks for the support... I really appreaciate the help and thanks for the offer of mailing you the GML but if possible (and I may resort to it) I prefer to try and understand what is happening and why it is happening myself if I am able...

One of my biggest issues is that this does not seem to be predictable... Eg something will work fine I save and reboot and it works differently after !! I thought I had it licked... Also seems mighty odd but when I use DVD2LCD.GML on its own all works fine, I import it into my working Girder GML and then it starts acting up... Worked around that by doing the reverse (importing mine into yours) but things like that confuse the hell out of me...

So what works fine and what does not....

I now have it so that TheaterTek will work perfectly... repeatedly opening closing etc all seems to be cool... This is as long as no other display using apps are also wishing to operate...

Media Jukebox however works fine but does not clear the display on closure of the application... Then there is crud on the display like the last title of song played and this will mess up other apps attemps at using the display properly as it only updates the screen where it wants to and this may not get rid of the chars that are left there... A clean screen close is needed for the MJ group (I am looking into copying what you have done with TT and will see if I can sort this)... I have also noted there are instances (not been able to get a repeatable pattern) whereby the clear screen (display -> DVD State -> Close I think) does not clear the VFD...

The clock... The clock is set to start at girder launch (does not always happen perhaps Girder launches before LCDriver is loaded ??) and then sits on the top line... Problems occur when the next piece of the puzzle wants to get control of the VFD as the clock hogs the top line... Really I would like a clock displayed whenever nothing else is using the display, otherwise clear it and give control to another function... Kind of like priority operation... having a list with which app get priority over another and when it releases it falls back to the next one down if you see what I mean... TT at the top / MJ next / Clock last... That way at the closure of all other apps the clock is displayed... I can see how this may be totally incompatible with the way you are currently working it but its just a thought...

I am clearly going to have to really work on plenty of multigroups that send clearing instructions depending on application open and closures...

So thats the major ones, then the minor ones...

When using MJ a lot of tracks are longer than 20 chars so using the scroll (marquee) feature would be nice... This does not work for me though... If I go to settings for the plug in for the variable title and set it to marquee the line vanishes.. Then the really odd thing is if I go back and set it rest of line with the exact config as it was before (column = 3) the line still wont come back !?!?! I dont know what I break when I do this but its puzzleing me... I notice a similar effect if MJ is minimized and the screen cleared (you will see why after the next paragraph) and then play is pressed on MJ... Track info (times / 1 of 12) comes back up but not track title...

I have a problem in my usage of MJ... I keep MJ in the system tray always so that I can connect to the HTPC via Glissando for remote control of my audio collection from a touchpad over 802.11... With this in mind I will have continual conflict between other apps and MJ in the system tray both wanting VFD control... In an ideal world MJ would only display when playing or paused... After a stop (displayed for 5 secs or so) the VFD should get a clear command so that other events can be displayed... Suggestions on a postcard please :) !!

So where can I start to learn how to play around with the layout of what goes up on the VFD ?? I would like to get the Artist / Album Name / as well as Track Name up on the MJ solution as Playing Bjork, Vespertine - Cocoon 2/12, time / Total time would be cooler.. .After all having all these tracks tagged should have some benfits... I am also keen to work on visual appeal by adding spacings etc and language 1 'of' 12 instead of 1/12

I can see that DVDSPy / Girder / LCDriver is going to take a long time to get the hang of... If this is the only way to get the complexity I need then I am OK with that but maybee I am asking too much...

[Phat Phreddy]

Francois, I dont suppose I could ask you to mail me the GML for that sort of stucture could you ?? This way I can pick through it and learn how you have set the commands... Phreddy@PhatPhreddy.net

Mike, I am going to have another couple of hours on this now and see how much farther (if anywhere) I get... Dont suppose you have any example of how I define variables and monitor state do you again GML's that show this action are very welcome... My VFD should support marquee mode (part of the powerbuy MO did with the ABeer cases) so will report what goes on with this...

Anyway it give me a reason to learn more about the nuts and bolts of girder rather than simply receiving RC5 codes and emulating keystrokes :D !!

[jason douglas]

Hi Phreddy,
I think I'm kinda struggling with the same problem you are, getting an HTPC setup with a VFD and multiple applications, and having it all controlled by remote. I'm still not totally done tweaking my setup, but hopefully I can offer some suggestions.
First off, about the marquee, I think all VFD's don't have marquee support. But because there refresh times are so fast, the software-marquee is quite sufficient... just go in the registry, and set the delay values to 0, and see if your VFD supports that. Mine did, and I don't see any lag in the marquee.
As for contention, I had the same problems, and fixed them by having several conditions... mainly, I have on and off commands for each app (theatertek and winamp are really the only ones I use), so each time I hit on for a app, i set a variable to disable the default display (when no app's are running), and when i hit off, it resets that variable, and has a goto action for the default display which loops until the variable is set again. You might need to set some delays between when an app releases the display, and another starts using it, otherwise you can run into problems. A second is usually sufficient.
Also, though, I use my apps exclusively (running winamp at the same time as theatertek is kinda senseless), so if you have multiple apps running simultaneously, you'll just need to create more variables (for instance, a fixed size array like app1, app2, app3, etc. where each app has a string of the app running, which is reset to "" when the app is done running. then you can have a big switch statement to decide which app's info to display, based on a priority list you define).
While I haven't gone this far yet, and probably never will, you're welcome to see the girder file I am using, and hopefully it'll give you some ideas! Just PM me if you're interested.

Hey, on a sidenote, McMM, did you code the DVDSpy plugin? If so, great work! Also, though, I was wondering if it was possible to make it so it doesn't keep sending the same event repeatedly when the payload doesn't change... for instance, I noticed when a dvd's playing, I keep getting a "PLAY" payload in the STATE event. Though it would've seemed simple to filter out redundant STATE events in Girder, I never could get it working properly, and eventually gave up, moving to a simpler solution. Maybe you'd have more luck than I did in removing the redundant events :D

[MMcM]

Hey, on a sidenote, McMM, did you code the DVDSpy plugin? If so, great work! Also, though, I was wondering if it was possible to make it so it doesn't keep sending the same event repeatedly when the payload doesn't change... for instance, I noticed when a dvd's playing, I keep getting a "PLAY" payload in the STATE event. Though it would've seemed simple to filter out redundant STATE events in Girder, I never could get it working properly, and eventually gave up, moving to a simpler solution. Maybe you'd have more luck than I did in removing the redundant events :D

Part of the problem is that it does not have a confident enough understanding of which events really are state-like in that the same payload means no change.

As a compromise, there is code there that suppresses duplicates of recently sent events by keeping a ring buffer of them. This should keep the same event from blasting constantly. How often are you seeing the duplicates?

Now that scripting is more powerful, it should be straightforward for a script that really cares to check the payload against a variable and only take action when it has changed. Most display-type applications don't really care about occasional repeats.