On Wed, Mar 8, 2023 at 5:34 AM Jeremy Nicoll <jn.ml.pyth...@letterboxes.org> wrote:
> Remembering that I don't use iTunes ... I wondered if the iTunes > application > (when you use it via its GUI) supports dynamic changes to a playlist when > that playlist is being played? > > Yes, you can alter live playlists at any time in the app itself. > I also wondered just how often your add/deletes failed? Are you adding a > track at the instant that your app notices that iTunes has just reached > the > end of one track and started the next, and presumably at that point > removed the just-played track from the playlist? > > That is, maybe there's a timing problem. If your code just happens to try > to > alter the playlist at the same time as iTunes is doing so itself, maybe > that > doesn't work - so maybe (if you're doing your change when you think it's > needed) you could wait 5 seconds and then try it. > > The old feature I'm trying to emulate was a 25-song rolling playlist in which the currently-playing song was actually song #6 in the playlist, providing enough songs have already played in order for it to get to song #6. It doesn't delete old songs until song #6 finishes playing. This means that once you actually reach song #6 you have a 5-song history in case you wanted to reference those or go back to any of them again for some reason. So you have a 5-song history, the currently-playing song, and 19 songs in queue at any given time. That's the behaviour my script is copying. So the songs that are being deleted from the playlist haven't been played in quite some time by the time it comes to actually delete it, and even with that, I've added a 1-second delay anyway. > It also struck me that in the GUI application - even if as a user you may > think > you can make changes to playlists at any time - the GUI may inhibit > user-made > changes for a few fractions of a second if IT is about to make a change, > but > the COM interface might just be offering you the code that makes the > change without the locking around it. > > So eg you might need to search the iTunes COM docs (I know there's some, > I found them, but maybe not uptodate, and maybe not complete?) for any > sign of "locks" or "serialisation" or "queuing" or "data integrity" > controls to > prevent the app and you simultaneously updating a data structure inside > iTunes. [I don't know the right terminology for this, other than on the > IBM > mainframes I used to work with, sorry.] It's also possible that - say - > it > renumbers or completely rebuilds a playlist structure whenever it changes. > I wondered if, if that's so, your code would get the rebuilt one each time. > > Well, if I'm there watching it as one song is about to end I can see that it deletes the song at the top of the list just fine, and adds a new song to the end of the list just fine, ignoring the fact that there are sometimes errors in the addition and it has to repeat addition attempts until it find one that works. It was my understanding that the song library was doing snagged and put into a local dicationary, and that this was where I was selecting my songs from. And also that the delete command only deletes the song from the current playlist, and only actually deletes the song from the filesystem in the case that you're current "playlist" isn't actually a playlist but rather the main library itself. So since I am deleting index 0 of the current playlist I don't think I should be getting any files deleted from the filesystem. I'm not attempting to delete the song itself by referencing the song entry it got from the library. I am attempting to delete my playlist's index 0 entry. I do have a backup of my library files just in case something like "Nah, bro, you're actually deleting files!" happened. I guess I should check to see if that's actually been happening. But the fact that I figured out where in the list failures were happening, and subsequent runs referencing the same file that errored actually succeeded in the later runs tells me I'm probably safe in that regard, or it would've failed on the same file again after it had actually been deleted. What strikes me as odd is how the references work fine as long as I haven't made a delete call, but after I make a delete call the references fail all over the place. It isn't just one reference that no longer works. It throws hundreds of random failures from each of the five groups in the 1000-test even though only one file has been through the delete call. I haven't timed it, but it takes something like 30-60 seconds to snag the library list from the app at startup. So I don't really want to have a master script to run a slave script that just makes one playlist update and exits, and loop that over and over. It'd be using up a lot of extra energy to make those 30-60-second calls every time a new song rolls over. Thanks for the reply, but this seems more like an iTunes problem than a python problem, so I guess it should just be left be. At least, there doesn't seem to be much point in cluttering up the python mailing list for something that now seems to be an app problem. Have a good one! -- Clayton Macleod If no one comes from the future to stop you from doing it, then how bad of a decision can it really be?
_______________________________________________ python-win32 mailing list python-win32@python.org https://mail.python.org/mailman/listinfo/python-win32
