[python-win32] possible data corruption when deleting iTunes playlist items

[Clayton Macleod]

On Wed, Mar 8, 2023 at 5:34 AM Jeremy Nicoll <jn.ml.pyth.93 at 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/python-win32/attachments/20230308/fa474843/attachment.html>