Dream Subsonic Client

[c0utta]

Hi Antonio,

I really appreciate the work you're putting into Tempo.

Having tried many Subsonic Android apps, I still use dSub because it just works.

I think I can sum up my requirements for a Subsonic Android client:

• sync playlists & favourite artists, albums & tracks using chosen codec at chosen bitrate when on WiFi
• when playing:
  • if on Wi-Fi:
    • direct play from server
  • if mobile:
    • play synced copy
    • if that doesn't exist, transcode and play according to chosen mobile codec and bitrate
• casting to Chromecast
• Automatic Replaygain
  • playing an album (not random), use Album Gain, otherwise use Track Gain

I think these are my (and I'm sure many) user requirements for an Android Subsonic client.

[CappielloAntonio]

Hi @c0utta, sorry if I'm only answering you now.

I think we're already ticking off a lot of the points on your list right now, aren't we?
it is already possible to decide how to play tracks based on the connection and based on whether it is a downloaded file or not since the first release, just as it is possible to cast on Chromecast. ReplayGain functionality was added in a later release and there are options for it in the settings.

[c0utta]

Hey Antonio,

No problem at all. Yes, a lot of the points have already been ticked off.

My point regarding "when playing" - are you confirming that Tempo operates like this already:

• WiFi: play directly from server
• Mobile: play synced copy, then stream
• No connection: play synced copy

My goal is to operate offline unless I play a track via mobile that has not been synced. This also means that you don't need an explicit "Downloaded" section because Tempo just handles it.

Some suggestions:

• setting for codec and bitrate for syncing
• setting for codec and bitrate when streaming via mobile
  Not sure that the settings are explicit enough in their description (for me anyway) maybe?

I note that Chromecast is not support within debug versions of the app. No problem, because easy workaround using Google Home casting.

Replaygain. Working as expected. I should have explained better. "Automatic" means "Smart" gain which will use "Track Gain", unless an album is being played in sequence (ie not random) which should use "Album Gain".

Some final questions:

• If I sync a playlist that contains synced favourites (via the setting), are those tracks synced again or does Tempo know that they've been previously synced?
• when do syncs occur? On a timer?

Love your work!

[CappielloAntonio]

Right now we can already decide how to stream based on the type of connection, whether in Wifi or using mobile data.

Two clarifications need to be made:

• If you leave the decision on streaming quality to the server, the settings on the streaming method in wifi and mobile data will be ignored.
• If you set the transcoding format in "Direct play" the bitrate settings will be ignored.

In any case, if a track has already been downloaded (maybe the term synced is a bit overused) the local file will be played and there will be no new download.

However, some clarifications should be made here:

• now (probably things will change in the future, but it requires major work) tracks are downloaded using Subsonic's API, which makes it impossible to define custom format and bitrate. If I request to stream a track in a different format than the original, Tempo won't find the file locally and will request the server again. I intend to change things, but that's the way it is at the moment.
• If a track was downloaded as a favorite, but is also included in a playlist that is being downloaded, the file will only be downloaded once.

As for the casting feature, you're probably testing the version with non-free components for the F-Droid store, which doesn't support the casting feature. A quick test to prove this is to look at the icon. If it's magenta then it's the full version, if cyano it's the version intended for F-Droid.

Finally, the download of the favorites takes place when the app is opened.

[CappielloAntonio]

• now (probably things will change in the future, but it requires major work) tracks are downloaded using Subsonic's API, which makes it impossible to define custom format and bitrate

You can now download a track with set codec and bitrate.

[c0utta]

Excellent work! You must have found an easy way.

As a non-developer, is it possible for you to do a release so I can download an .apk?

[CappielloAntonio]

Yes, sure. I just released a new pre-release version.

[c0utta]

Hmmm. With this release I can't play or download any tracks at all.

[CappielloAntonio]

Hey, I'm so sorry to hear that. I think it's one of the consequences of all these changes on the download system made in this release.
Among all the improvements made, backwards compatibility for those who already used the old download system may have been affected. I'm really sorry.
Do new downloads have the same issue? Did you try to download new tracks?

[c0utta]

I expect issues with a pre-release, so no problem.

This was a fresh install of Tempo - no changes to settings and no previously downloaded items. Connected to server - browsing worked correctly.

Playing a track loads the track but stops within 2-3 seconds with no playback. The "playing" screen play/pause button changes, indicating that the track has paused.

Downloading items doesn't download - I note that there are "Download failed" notifications but nothing within Tempo.

Cheers

[CappielloAntonio]

It's all very weird. If you erase all the data and start from a clean base, do you get the same problem? Connecting to your server I downloaded and played some tracks, so I exclude that the problem is the server.

[c0utta]

I'm sorry Antonio - my fault. Using http instead of https has caused this issue. How embarrassing....

I will test Tempo vs my requirements and report back.

[CappielloAntonio]

Don't apologize, none the less it's a weird situation.
I decided to step on the accelerator with the release of the new version because if more and more people use the old one, when the new version would have been released they would have found themselves in a hybrid situation with downloads, managed a little in the old way and a little in the new way.

[c0utta]

I've done some testing.

In short, sync works as expected (I must have too many downloaded items, because "Download" causes Tempo to crash). I was able to download some starred items as "Original" first, then changed setting to [Opus] [256 kbps] for all other downloads.

Before I can comment on playback, I believe there is a bug that needs to be fixed with the [codec][bitrate] display at the top of the "Now Playing" screen:

Settings:
Transcode format in Wi-Fi: Original
Bitrate in Wi-Fi: Original
Transcode format in mobile: Opus
Bitrate in mobile: 32 kbps
Transcode format for downloads: Opus
Bitrate for downloads: 256 kbps

• no Wi-Fi (on mobile). File has been downloaded, so [opus][32kpbs] is not correct. This should be [opus][256 kbps]

• "flight mode". Always shows original bitrate instead of actual (which should be [opus][256 kbps])

Are you able to confirm that these values are incorrect?

[c0utta]

Hey Antonio, wondering if you've had a chance to look at this yet?

[CappielloAntonio]

Hey @c0utta yes I am aware of the problem.
Unfortunately I have no way of knowing what the bitrate and codec actually used by the mediaitem being played is.

Let me explain better. When Tempo plays the music file, it reads the information on codec and bitrate not from the file itself, but from the metadata that the server returns.

var contentType: String
var suffix: String

When the server returns a transcoded file, the contentType and suffix values remain the same as the original file.

I would expect two more values to be validated, but at least navidrome ignores them:

var transcodedContentType: String
var transcodedSuffix: String

This preamble to say that since I don't have the information directly from the server on bitrate and codec, I must necessarily see the codec and bitrate that the user has requested in the settings which does not necessarily correspond to the real codec and bitrate of the file.

In fact, the server may not support those transcoding settings.

The same thing goes for downloaded files. The user from the settings could set a specific bitrate and codec, but the server could not support it. In that case I find myself downloading the file, saving the contentType and suffix parameters passed to me by the server, not knowing however if what I'm listening to really corresponds to those parameters.

I can mitigate the problem by warning the user when choosing transcode and transcode download settings that the server must support the required settings, or with a graphic indication on the music player screen.

I'm still studying the situation, I wanted to let everyone know, but unfortunately the room for maneuver is not that wide.

[c0utta]

Hi Antonio,
I am not an Android developer, but I assume that reading the codec and bitrate from the file as it is loaded is impossible?
Therefore, could I suggest to display "Downloaded" or "Local Copy" instead of the incorrect information? You could then display the true bitrate only when streaming.
Cheers