This could cause a problem. If we delete the old FID, we'll only delete the files that we know about. Then, when we reuse the FID, it'll get associated with the (left over) wrong lyrics file.

Yes. However, if, instead of FD3L, lyrics lived in, say, FD3A, then Emplode would delete them when deleting the fid -- Emplode passes (the default) mask of 0xFFFF to ProtocolClient::DeleteFid, which means that all sixteen files FD30..FD3F get deleted when FD30 goes away.

Now, such *A files are technically reserved for use by Empeg, but as we've only so far used *0, *1, and *2 (and the last only on Jupiter), plus *F which has a special meaning to the protocol, it seems likely to me that car-player people using *A will in practice be safe for the time being. This also means that Java mateys and so on don't need to add anything new to the protocol to be able to store or fetch these files.

Unfortunately, the current version of Emptool tries to be clever but isn't -- it passes a mask of 0x3 in what, judging from a nearby comment, is an attempt to delete *0 *1 *2 and *3. In fact this deletes only *0 and *1 and is thus already wrong on Jupiter -- I'll fix it for 2.0final to pass 0xFFFF, if I remember.

Peter