MTP gsoc nexus 4 testing

[Matěj Laitl]

[adding amarok-devel to CC as this contains some general discussion]

On 25. 9. 2013 Bart Cerneels wrote:
> [Bart was testing my GSoC code, providing lot of useful feedback]
>
> Starting Amarok *after* plugging in the MTP device and closing
> nautilus does work. I would put that in a warning dialog. Make sure it
> can be disabled from appearing again with a checkbox.

I've added a passive notification, please check that it appears in your case.

> Matěj Laitl wrote:
> > Bart wrote:
> > > I was a bit confused because I didn't see the N4 yet in collection
> > > browser while it was shown to be scanning message area. Can the
> > > MtpCollection be registered before scanning is started?
> > 
> > It behaved like that in the past, but it had 2 downsides:
> > a) it showed empty collection for significant time, because we get the
> >  tracks at once at the end, we only get the progress reporting before
> >  (but work-aroundable, but it would be a hack)
> > 
> > b) MetaProxy::Tracks listen to collectionAdded() and then query the
> >  collection right away. If it is not (yet) ready, the resolving fails for
> >  the tracks, which means that playlist won't be preserved.
> > 
> > My proposed solution is to introduce Collection::Status { Updating, Ready
> > } and make other parts act accordingly, including visual display.
> 
> Collection::Status is a good stop-gap solution and can be useful for
> other states as well: Error, Network Problem, etc. It could be useful
> regardless of Proxy handling.

I wouldn't even consider it stop-gap. The Collection Browser could show 
"Updating..." instead of track count and perhaps even some animation.

> Changing the way MetaProxy::Track listens to collection changes
> (trackAdded, etc) would solve it completely, but it think that would
> be a huge change.

I've thought about it, but rejected it as too demanding performance-wise. If 
every unresolved proxy track would watch for every collection's updated() 
signal (and then perform a search in the updated collection), the update() 
could easily get very costly. (imagine 100 of unresolved tracks and iPod 
collection that emits updated() that emits updated() every second during 
loading to keep UI updated).

Note that neither Collection nor TrackProvider currently has any sort of 
trackAdded() and adding it would place a way too heavy burden on existing and 
new collections (remember that only public interface to see collection's 
tracks is its QueryMaker, the collection doesn't even need to know complete 
track count before querying them).

> >> Seems to have a problem with FLAC files. They're shown under Unknown
> >> Artist/Unknown Album; some with titles as mtp://Internal
> >> Storage/..../xxx.flac, others do have titles. The metadata is readable
> >> by taglig, these are perfectly fine in Local Collection. Guess this
> >> depends on the device's MTP reading the metadata?
> > 
> > Yes. But we work-around it by reading the tags from the file (unless
> > disabled) as soon as it is cached locally. You may try to play them or
> > transfer to another collection. I may add optional support for
> > opportunistic caching, OTOH it temporarily needs quite a bit of space.
> 
> Google's Play Music does read those FLAC files correctly. A bit
> strange that the MTP handler doesn't, but nothing surprising in such a
> large complicated system.

Yeah, this is the sad truth, on my Samsung S III Mini Google Play Music can 
for sure read track numbers and the default player can also read year etc., 
but neither track numbers, album artists or years are presented on MTP side!

> Do we know what metadata protocols/versions it does support?

Yes, for example Nexus 7 says it can read only name from flac files, while it 
claims it can read Name, Display Name (?), Artist, Album Name, Album Artist, 
Track, Original Release Date, Duration, Genre, Composer from MP3 files.

OTOH, my S III Mini *claims* it can read (also) Track, Album Artist etc. from 
MP3s but it doesn't actually do that, so we cannot trust this information. :-(

> Could you rewrite tags when copying to MTP?

Yes, unless you disable "Read & Write file metadata" in the config dialog.

> >> I just managed to lock up Amarok, at least the GUI thread.
> >> Unplugged the N4 while track from it were playing. The upcoming tracks
> >> were greyed out in the playlist, as expected (but only after
> >> mouse-over -> missing QAIM datachanged signal). Then I double clicked
> >> on a greyed-out track anyway and it locked up.
> >> 
> >> Culprit: probably EngineController expecting data that will not be
> >> downloaded. Here are the last log lines: (...)
> > 
> > (...) you've actually
> > spotted a bug, that went it during refactoring, now it creates and empty
> > file in this case, which is silly.

It is fixed now and should no longer hang even with phonon-gstreamer.

Regards,
	Matěj