THC Jukebox

[markd]

Still plugging away. . .

Questions-

1) Why do you create and destroy the objDB every pass through the message handler?

2) I'm thinking I'm going to split the import function into a separate script- can you see any reason not to do this? This is tied to making the script multi-zone.

3) Why do you use "Allow Run Jukebox Script" to stop the script from running while populating the library? How is that different from just sleeping it?

4) Multi-zone- I'm coming around to your "one script to rule them all" . My thought is to add a Zone string variable in front of the device references- Jukebox, MusicPlayer, and Keyboard, as well as adding/mapping it to the songqueue as you mentioned above. Only other spot I see collisions are the files that hold the coverart. Then I can modify the Do-Loop at the top of the file to check each of the zones sequentially. Thoughts?


Changes I have already made-

-Double-clicking an Artist lists the Albums rather than the songs.

-Clicking all to Q work for albums too- all songs are added to the Q

-Moved the library page up and page down subs inside the checks- otherwise there are spurious pg up and pg dn commands since the sql generated doesn't always match what you expect.

Still to do-

-be able to back up from drilling down Artist-Album-Song. My expectation is that Hitting Album would take me back up to a list of Albums by that Artist, rather than listing the albums filtered by the selected letter.

Thanks for any input

Markd

[incoronado]

I glad to see you are making some great additions and learning along the way. I will look through the code tonight and get you some answers. There was a reason I create and destroy the objDB every pass through the message handler. The reason escapes me at the moment, but a trip through the code will probably jog my memory.

Regarding "I'm thinking I'm going to split the import function into a separate script- can you see any reason not to do this? This is tied to making the script multi-zone."

I thought about doing that, but I thought multiple scripts would make it more difficult/complicated to package for other users.

Without knowing more about how you are using the import function I couldn't answer that. I guess I don't understand why the import function would affect multiple zones. The import function merely merely saves all of the ID3V2 tag information to a SQL table. All zones could access the same imported data and shouldn't be a need for separate import routines. Then again, I'm speaking from recollection at the moment.

I will take a look at this when I get home this evening.

[markd]

On the import, I just don't want it on all my screens- it is kind of a maintenance function for me- not really related to the rest of what is going on with the jukebox. It isn't really hurting anything, just don't need it in there. . .

Thanks

Markd

[incoronado]

In that context, makes a little sense.

[Richard Naninck]

1) Why do you create and destroy the objDB every pass through the message handler?

Markd

This turned out to be a good question. It was done because the jukebox is based on Meedio databases and thereafter ported to WinAmp by Incoronado. I handle multiple databases with the script and Meedio can lock a database when it is updating. This made me open and close the database any time a command was handled. I just tried keeping the database open all the time and it works without any lockups whatsoever. The good thing about it is that all is a bit quicker now since the database remains open. The downside is that during expirimenting / programming, a running script is stopped and rerun multiple times by HouseBot. In this case the database doesn't get closed the way it should. I am not sure if this is a problem since the whole thread should be removed. I have seen on multiple occaisions that a script remains active in the background even when it is stopped by HouseBot. This causes very strange behaviour because stuff might happen twice where you expect it only once. It happens twice because of the fact that the same script is running twice.
This can be fixed by introducing a command to stop a script so it can close all of the opened dll's and set the declared variables to Nothing.

Anyways, I guess it is safe to say that the Open and Close can be removed from the handle action sub and the Open can be moved to before the Do and the Close can be moved to after the Loop.

Hope that makes sense...

[incoronado]

Yes. I agree. If I remember right, I even tested this and found it to occasionally lock up., or time out, as Richard mentions went it got caught in a long SQL write operation. It is possible for a script to get called recursively or write another script later on that uses the same database silmultaneously. It seemed like good practice to free it up as much as possible. SQLite is smoking fast because it doesn't suffer the additional granular record/field locking overhead as more robust RDBMS SQL databases require because they are not stand alone and need to account for simultaneuos connections from many different sources. But it is very good as a stand alone SQL database. And for this application, like Meedio, it is perfect.

[markd]

Anyways, I guess it is safe to say that the Open and Close can be removed from the handle action sub and the Open can be moved to before the Do and the Close can be moved to after the Loop.

Hope that makes sense...

All except the part about moving the Close to after the loop- wouldn't that mean it will never be executed?

I'll probably add a command to shut it down, especially if I end up moving the import to a separate script, since it operates on the same database. For debug, I'll probably leave it where it is just for convenience.

I agree that SQLite is great for this application!

Any input on question 3?

Thanks

Markd

[Richard Naninck]

Anyways, I guess it is safe to say that the Open and Close can be removed from the handle action sub and the Open can be moved to before the Do and the Close can be moved to after the Loop.

Hope that makes sense...

All except the part about moving the Close to after the loop- wouldn't that mean it will never be executed?

I'll probably add a command to shut it down, especially if I end up moving the import to a separate script, since it operates on the same database. For debug, I'll probably leave it where it is just for convenience.
Markd

Correct, it will never be executed when HB does the stopping part. That's why a separate stopping command should be incorporated which can kill the Do Loop. I just put it there because all that is opened in code should also have a close command. If all is well, HB should remove the thread correctly and the databse does close. No problem in doing it this way. I runs fine in my scripts.