Questions regarding MediaPlayList

[Matthieu Gallien]

Hello,

Sorry for the delay.

On jeudi 10 mai 2018 18:08:07 CEST Alexander Stippich wrote:
> 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.

Thanks for your work.
Let me know if I can help on this work. It would be really nice to have it in 
the next release.

> > > 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?

I had designed it to have mData always filled and asynchronously fill 
mTrackData.I would have to only save mData to save a playlist.

We can always change the behavior if there is a good reason to do so.

> > > 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.

Yes, it seems we have one bug to fix here.

> 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
> 
> _______________________________________________
> Elisa mailing list
> Elisa at kde.org
> https://mail.kde.org/mailman/listinfo/elisa