savonet

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

Hi,

I could have checked immediately, that was easy, the following doesn't
work (and it's the same length parameter):
# liquidsoap 'out(playlist(length=0.,"~/media/audio"))'

If the length is null, nothing moves to the primary queue and nothing
gets played. So the best that you can get now is to set length to, say
0.1, and only one track will be prepared in advance.

Cheers.
-- 
David

Le Thursday 20 September 2007 08:48:17 David Baelde, vous avez =E9crit=A0:
> 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.

Couldn't it be nice then to seperate this in telnet/socket printing ?
Ex:
>> request.queue
loaded: 14 13 17=20
awaiting: 18 19 20 21 22 23 24 25

Or perhaps better..

Romain
=2D-=20
The music hits you,
But you don't feel no pain

Mmm... it's true that currently, one has to guess that there are two
different statuses. There are other ways to hint at that, by adding
information in error messages for example.
The current system is being used by liguidsoap nicely. It gets the
extra status info from the metadata. So in any case, if we change the
output of that command, it has to be changed accordingly in lig.
-- 
David

>>>>> "DB" == David Baelde <david.baelde@...> writes:

    DB> Mmm... it's true that currently, one has to guess that there
    DB> are two different statuses. There are other ways to hint at
    DB> that, by adding information in error messages for example.
    DB> The current system is being used by liguidsoap nicely. It gets
    DB> the extra status info from the metadata. So in any case, if we
    DB> change the output of that command, it has to be changed
    DB> accordingly in lig.

Instead of changing the output of existing commands you could add new
ones. In addition to what Romain suggested it would also be nice to be
able to get queued playlist entries in the same format. In general I
wish there were more control over the liquidsoap behavior, maybe a
higher level interface?

Thanks,

-- 
Viktor