[livesupport-dev] accessPlaylist recursive - Airtime Development Discussions on Sourcefabric Forum

import

On Tue, 30 Aug 2005 11:53:09 +0200

import

> It looks not critically difficult.
>
> RFC:
> locstor.accessPlaylist method would have additional optional parameter:
> recursive: boolean (default=false)
>
> and if it's set to true, there will be additional field in the returned
> struct:
> files: array of accessRawAudioData structs
> (structs which are normally returned from accessRawAudioData method:
> {
> 'url': string /*local access URL*/,
> 'token': string /*access token*/
> }
> )
>
> It would go through playlist, open all audioClips inside and return all
> returned values in the array.

and what about releasing the files? do we have to release them one by one...

> In the first step it will not handle nested playlists.

that's bad...

>
> Akos, are you able to handle it from GUI or it have to wait for Ferenc?

I'll do my best..

------------------------------------------
Posted to Phorum via PhorumMail

import

On Tue, 30 Aug 2005 17:41:24 +0200 (CEST) darkeye@tyrell.hu wrote:
> ...
> > It would go through playlist, open all audioClips inside and return all
> > returned values in the array.
>
> and what about releasing the files? do we have to release them one by one...
>

*** do you want something completely transparent?
what about this:
- if the "recursive" param of accessPlaylist method is set to true,
all audioClips inside are open and only local access urls are returned
in "files" field (:array),
- all access tokens are associated with the playlist and audioClips
are automatically released on playlist release

OK?

> > In the first step it will not handle nested playlists.
>
> that's bad...
>

*** I know, but it's better to divide problem and the second step could be soon ...

> >
> > Akos, are you able to handle it from GUI or it have to wait for Ferenc?
>
> I'll do my best..

*** It's important for decision if it is worth to finish it over this night or not.

Tomas Hlava
th@red2head.com

------------------------------------------
Posted to Phorum via PhorumMail

import

> *** do you want something completely transparent?
> what about this:
> - if the "recursive" param of accessPlaylist method is set to true,
> all audioClips inside are open and only local access urls are
> returned
> in "files" field (:array),
> - all access tokens are associated with the playlist and audioClips
> are automatically released on playlist release
>
> OK?

yes, this sounds good...

> *** I know, but it's better to divide problem and the second step could be
> soon ...

yes, this would be nice, if soon is within the next days...

> *** It's important for decision if it is worth to finish it over this
> night or not.

I would need the version with the embedded playlists by tomorrow afternoon.

Akos

------------------------------------------
Posted to Phorum via PhorumMail

import

On Tue, 30 Aug 2005 18:49:58 +0200 (CEST) darkeye@tyrell.hu wrote:
> > *** do you want something completely transparent?
> > what about this:
> > - if the "recursive" param of accessPlaylist method is set to true,
> > all audioClips inside are open and only local access urls are
> > returned
> > in "files" field (:array),
> > - all access tokens are associated with the playlist and audioClips
> > are automatically released on playlist release
> >
> > OK?
>
> yes, this sounds good...

It's commited!

Both locstor.accessPlaylist and locstor.releasePlaylist have
additional optional field in input struct:
recursive: boolean (default:false)

The locstor.accessPlaylist method have additional field in return struct
(only if recursive is true):
files: array of strings - local urls of audioClips
Nested playlists are handled recursively too (2 level nesting tested).

The locstor.releasePlaylist method automatically release all clips and
nested playlists previously accesses by recursive locstor.accessPlaylist.

Unfortunately the new association between opened playlist and files inside caused
little db structure change => reinit of storageServer db is needed.
(or run: "alter table ls_access add parent bigint;" in psql)

RESULT: on testing playlist (3 audioClips + 1 nested playlist with 2 audioClips)
have average response cca 0.5s for access+release all the playlist.
=> for short playlists it should be OK.

Tomas Hlava
th@red2head.com

------------------------------------------
Posted to Phorum via PhorumMail

import

Tomas Hlava wrote:
> It's commited!

excellent!

>
> Both locstor.accessPlaylist and locstor.releasePlaylist have
> additional optional field in input struct:
> recursive: boolean (default:false)
>
> The locstor.accessPlaylist method have additional field in return struct
> (only if recursive is true):
> files: array of strings - local urls of audioClips
> Nested playlists are handled recursively too (2 level nesting tested).

great...

>
> The locstor.releasePlaylist method automatically release all clips and
> nested playlists previously accesses by recursive locstor.accessPlaylist.
>
> Unfortunately the new association between opened playlist and files inside caused
> little db structure change => reinit of storageServer db is needed.
> (or run: "alter table ls_access add parent bigint;" in psql)
>
> RESULT: on testing playlist (3 audioClips + 1 nested playlist with 2 audioClips)
> have average response cca 0.5s for access+release all the playlist.
> => for short playlists it should be OK.

good to hear.

one more though: do we know where is most of the time spent now in
accessing files? is it maybe with creating symlinks to the files
themselves? how would the performance change if no symlinks were
created, but simply the file location would be passed?

(I remember your security concerns and the argument behind the symlinks,
I'm just curious about the performance hit...)

import

Tomas Hlava wrote:
> Nested playlists are handled recursively too (2 level nesting tested).

I'm having problems with nested playlists, see
http://bugs.campware.org/view.php?id=1438

Howdy, Stranger!

Categories

Poll

Top Posters