Hi Viktor, The two request queues implement an user-manageable "secondary" queue built on another abstraction which already has a "primary" queue. This primary queue is used for example in playlist sources to prepare (download and check) requests in advance, to avoid failures.
While you can edit the secondary queue, it is not possible to do anything with a request which has entered the primary queue. That's certainly what happens to you here. With a request.queue() there is a message in the request's trace notifying the move to primary queue, but I just realizing that no such thing is done with the editable queue. The solution is to lower the precautions taken with the primary queue, by setting a shorter length parameter (0. might work, or not.. I don't think I ever tried). At least you should be able to avoid that two files get prepared in advance. I'll try to have a look at it and see if it's possible to not prepare anything in advance -- which is fine if all your requests are local files. Cheers. -- David
