Questions regarding MediaPlayList

[Alexander Stippich]

Hello,

On Donnerstag, 10. Mai 2018 13:59:33 CEST Matthieu Gallien wrote:
> Hello,
> 
> On mercredi 9 mai 2018 20:56:24 CEST Alexander Stippich wrote:
> > Hello,
> > 
> > I'm slowly working towards handling files with little to zero metadata,
> > which is needed for a file browser. I'm struggling a little bit with the
> > mediaplaylist currently, specifically with tracks enlisted only by url.
> 
> Could you share your feature branch such that others can look at it ? You
> did that for HighDPI and in my opinion, it has worked well.

I actually wanted to do that earlier, but the build system changes made 
rebasing quite painful. That's why I started pushing smaller pieces into the 
codebase that are somewhat useful on their own. I started now on a fresh 
branch for the file browser and copy the remaining new files over. Should be 
done soon.

> > I never really understood the duplication between the MediaPlaylistEntry
> > data lists and the lists of MusicAudioTracks, can you elaborate a little
> > bit on that?
> 
> My main idea is to have the playlist store its tracks independently of where
> they are. They could be in the local music database or in an UPnP/DLNA
> share or from a local file or somewhere else. It is also possible that an
> existing track in the playlist has been moved to another path.
> If we store the tracks by their path, we cannot restore a playlist with a
> track for which the path is not the same.
> To allow for more flexibility, I had added the possibility to also have
> tracks being identified by their path. This should be working fine but
> force to compute their metadata after the tracks has been added.

Are the entries in mTrackData always tied to a corresponding track in the 
models? To be more precise, I'm talking about the mData and mTrackData lists.
Cannot the mTrackData list with MusicAudioTrack also handle all the different 
cases?

> > Anyways, there is a bug that also affects enlisting tracks via the command
> > line.
> > If you add the tracks via url, they get added to the mData structure with
> > a
> > corresponding, empty MusicAudioTrack (I think). This makes displaying etc.
> > really difficult and currently completely fails. The scanning of metadata
> > is only happening afterwards, since the url is given to the
> > TracksListener, which does the scanning for metadata. It seems that it is
> > not updated afterwards.
> 
> Yes, fetching the metadata should be asynchronous. It should be the case
> when you want to queue a track by its path instead of by its metadata. What
> is the problem you are seeing ?

Pass an audio file as command line argument to Elisa, the title should not 
show up. I think that's because I changed the code previously to work only on 
the trackdata column of the model with the trackdatahelper, which requires the 
data to be filled in the corresponding mTrackData entry. This is not the case 
when adding via an url.

Thanks and best regards,
Alex
> 
> > I think we need to fill the MusicAudioTrack immediately, I'm just not sure
> > how to do it properly. One could move the scanning to MediaPlayList, but I
> > think this would block the UI. Thoughts?
> 
> You cannot fill the MusicAudioTrack immediately in the main thread. Reading
> metadata via KFileMetaData takes some time and the delay should be
> noticeable.
> > Best regards,
> > Alex
> > 
> > 
> > _______________________________________________
> > Elisa mailing list
> > Elisa at kde.org
> > https://mail.kde.org/mailman/listinfo/elisa
> 
> Best regards
> 
> --
> Matthieu Gallien
> 
> 
> _______________________________________________
> Elisa mailing list
> Elisa at kde.org
> https://mail.kde.org/mailman/listinfo/elisa