Bug 498169 - Can't play files directly from phone using KDEConnect
Summary: Can't play files directly from phone using KDEConnect
Status: RESOLVED FIXED
Alias: None
Product: amarok
Classification: Applications
Component: Collections/USB mass storage and MSC (show other bugs)
Version: 3.2.0
Platform: Fedora RPMs Linux
: NOR normal
Target Milestone: kf5
Assignee: Amarok Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-01-02 15:54 UTC by John
Modified: 2025-02-21 22:49 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
Error Screenshot (13.09 KB, image/png)
2025-01-02 15:54 UTC, John
Details

Note You need to log in before you can comment on or make changes to this bug.
Description John 2025-01-02 15:54:12 UTC
Created attachment 177046 [details]
Error Screenshot

SUMMARY
When i try to access an android phone and add remote files on that phone to the Amarok play list returns an error and does not me allow to navigate the device

STEPS TO REPRODUCE
1. Pair a device using KDEConnect
2. Expose phone folder to the connection (share directory)
3. check if it can be accessed from dolphin
4. open amarok and, on the left pane, go to Files and select the device

OBSERVED RESULT
it returns an error

EXPECTED RESULT
we should be able to navigate remote device, add files to the play list and listen to them

SOFTWARE/OS VERSIONS
Operating System: Fedora Linux 41
KDE Plasma Version: 6.2.4
KDE Frameworks Version: 6.9.0
Qt Version: 6.8.1
Graphics Platform: Wayland


ADDITIONAL INFORMATION
I can navigate to the remote directory in Dolphin and open the files in Amarok however (if i wait long enough...because the access is REALLY slow)
Using this last workaround, the music tends to stop from time to time...
Comment 1 Tuomas Nurmi 2025-01-04 09:58:56 UTC
Thank you for the report!
I tried reproducing with pretty much similar results. Might be multiple factors affecting this. Amarok being Qt5/KF5 and Dolphin + desktop Qt6/KF6 might contribute (similarly to kio_audiocd5 & kio_audiocd6 discussed in other bug reports), or at least makes finding the root cause a bit harder. I'll try and see at some point if this is reproducible (+ fixable) with Qt6 build of Amarok.
Comment 2 Tuomas Nurmi 2025-01-05 11:23:50 UTC
Tested with Qt6/KF6 build of Amarok on Plasma 6 desktop and everything pretty much seems to work. So this one should get fixed when the default build changes from KF5 to KF6.
Comment 3 John 2025-01-06 12:50:56 UTC
That's great news!!! 
(well... maybe not so great-great since it will take a year for amarok 4.0 to be out... but still nice)

I have a buch of music files on my phone that i don't want to transfer to the desktop computer (because the phone is mine, but the desktop is from my company), but i still wanted to listen to "that music i have on the phone".

Will be great to be able to do so :)

Thank you and Happy 2025
Comment 4 Tuomas Nurmi 2025-01-06 12:58:28 UTC
Probably not quite that long: I've come to the conclusion that it'll probably make sense to do an Amarok 3.3 release in Spring, where Qt6/KF6 might be the default build already (or at least distributions will likely package optional Qt6 versions), so just a couple of months.

Thank you, as well!
Comment 5 John 2025-01-06 15:32:20 UTC
(In reply to Tuomas Nurmi from comment #4)

> probably make sense to do an Amarok 3.3 release in Spring, where Qt6/KF6
> might be the default build already (or at least distributions will likely
> package optional Qt6 versions), so just a couple of months.

A Qt6/KF6 as default in the spring would be awesome!!!

I, personally (if you allow an user voice about it...), think that an Amarok 4.0 - in the Spring - would better mark the transition to Qt6/KF6 as default!
It could get out without any further improvements beside that transition and then have enhancements in a 4.1...

Independently of the number chosen, i love the idea of having a Qt6/KF6-default version release soon!!!

we've been so long without it that i think everyone is eager to get our hands on an updated version :)
Comment 6 Tuomas Nurmi 2025-01-10 16:27:02 UTC
Thank you for the comment! Yes, it would of course be kind of nice to have a fresh new major version number. However, some viewpoints that make me favour the idea of 3.3 is the fact, that time from 3.2 to 3.3 (Qt5 default to Qt6 default) will be shorter than from 3.3 to 4.0 (roughly equal featureset to previous vs great bunch of new features, for which I've tried to outline some plans at https://invent.kde.org/multimedia/amarok/-/issues ), and also; I remember KDE 4.0 - the discrepancy between the expectations for the fresh new future vs the actual case of focus being getting a ".0" for a very much renewed technology stack.

There's a lot that could - and should - be done (4.0), but a very reasonable amount of work will ensure that the lights stay on for many many many more years as is (3.3)
Comment 7 John 2025-01-16 15:52:06 UTC
(In reply to Tuomas Nurmi from comment #6)
> I remember KDE 4.0 - the discrepancy between the expectations for the fresh
> new future vs the actual case of focus being getting a ".0" for a very much
> renewed technology stack.

yeeeeaaahhh.... i remember KDE3>KDE 4.0 also.............. lets just leave that skeleton in the closet............ ahahah
it did prove the right move, but that 4.0 should have been a beta or a 3.9.999...

So, I think you may have a point here! Better learn from the past and stick to 3.3 :)
Comment 8 John 2025-01-16 15:59:52 UTC
Anyway, having "Qt6 default" in in the next release (3.3 or whatever you end up calling it) is, imho, a must have!
Comment 9 Tuomas Nurmi 2025-02-21 22:49:06 UTC
Git master has now been migrated to Qt6/KF6 default, so this should be now fixed. Closing.