UPNP seek problem

Issue description:

I have all my media downloaded via the download option in the media provider.
My dlan speaker/ setup is described here: Remote control from one instance of Symfonium to another? - #34 by gamebeaker
*.m4a problem:
Most of my *.m4a files get skipped.
Fix:
ffmpeg -i input.m4a -c copy -movflags +faststart output.m4a
(general information for you could be a solution for Can't stream *.m4a music files to my Technisat and Hama Network Player)

*.opus problem:
I am unable to seek them i only see the current time increasing but no “goal” time.
The few *.m4a files that work don’t have this problem.

Logs:

Upload description: gamebeaker3

Media provider:

WebDAV

Screenshots:

 

    
edit1:
I have found that the container throws an exception:
exception: Not seekable
I opened a github issue here:

You need to see with the receiver side for both.

@Tolriq I was able to “fix” the opus playback issue from the server in this github issue *.opus exception: Not seekable · Issue #414 · GioF71/mpd-alsa-docker · GitHub thanks to GioF71.
My issue now is that symfonium handles different provider different even if i have “Proxy via Symfonium” active.
Media provider local device:
The opus file can be casted and seek functions properly. Skips are instant (very responsive).
Media provider WebDav:
The opus file can be casted and seek doesn’t work. If i skip a song it takes 3 - 5 seconds before it is skipped.
I have all tracks locally with the option “Automatic media offline cache” active.

What i did in the uploaded logs (description: gamebeaker4opus):
As preparation i created a playlist with 2 tracks the first track is from the WebDav provider the second track is from the local provider.
The first and second track are the same file.

  1. I cast the first track and play it a few seconds with the observation that seek doesn’t work.
  2. Skip to the second track.
  3. See that seek works and pause the track.

The proxy mode is just a proxy mode, so it returns the headers of the original server. (And not used when casting from local device)
Symfonium have 0 impact on whether a media can be seeked or not in that case.

When you cast, Symfonium always use the server and not the cache if the server is available as it’s usually more efficient.

If i disconnect my network from the internet seeking works.
I guess that symfonium realizes that there is no internet and casts in offline mode the downloaded files directly.

When you cast, Symfonium always use the server and not the cache if the server is available as it’s usually more efficient.

So it is more efficient that Symfonium downloads the song and than forwards this song to the casted server instead of just casting it directly from cache?

If i look at the mpd logs i don’t see a difference between “Proxy via Symfonium” enabled or disabled. Mpd tries to play a url that looks like this for WebDav: http://192.168.0.32:38117/46412b9cac55842fb76b6771d95a5729/https%3A%2F%2Fnx39171.your-storageshare.de%3A443%2Fremote.php%2Fdav%2Ffiles%2Fgamebeaker%2FMusik%2FMusik%2F8%2520Graves%2FAlbum%2520-%2520Hello%2520Jupiter%2FBored%2520to%2520Death.opus
Local Device:
http://192.168.0.32:38117/ab4345353db84acc1c83e2b706137fff/primary%3ADownload%2FAlbum%20-%20Hello%20Jupiter%2FBored%20to%20Death.opus

Maybe it is a new option for upnp casting something like “offline mode”. I thought that this is the normal behavior as when i listen to music without casting and have it downloaded it doesn’t try to stream it from the internet it just takes the downloaded version. (Or does it?)

It does not download it proxies the data as the option that you enable ask it to.

And yes it’s more efficient even in that case as there’s no sdcard access and less battery usage.

When you play locally then offline cache is used as it’s more efficient.

The 2 questions are:

  • Why do you need to proxy at all as it should not be necessary.
  • Why does seeking when getting the webdav headers does not work.

I’m pretty sure you don’t need to proxy, and that seeking from webdav can be fixed too as you fixed the other case.

And yes it’s more efficient even in that case as there’s no sdcard access and less battery usage.
When you play locally then offline cache is used as it’s more efficient.

Ok proxy is more energy efficient. I just thought that as symfonium is offline first that it takes the downloaded data.

Why do you need to proxy at all as it should not be necessary.

Seek doesn’t work with and without proxy. I don’t see a difference in behavior. I had a misunderstanding about what proxy does.

Why does seeking when getting the webdav headers does not work.

I am not sure here are the different headers:

headers where seek works:

mp3_webdav_offline_respone_header_with_proxy_plays_track_in_chrome

http://192.168.0.32:41141/5307b30c7765e9327243dafcfad46d68/%2Fstorage%2FEF9C-68FF%2FAndroid%2Fdata%2Fapp.symfonik.music.player%2Ffiles%2FOfflineMedias%2F2%2F2856E953F624F9367CB24B96B7510FC4.mp3
HTTP/1.0 200 OK
Content-Type: audio/mpeg
Date: Thu, 2 Jan 2025 19:20:07 GMT
Accept-Ranges: bytes
ContentFeatures.DLNA.ORG: DLNA.ORG_PN=MP3;DLNA.ORG_OP=01;DLNA.ORG_CI=0;DLNA.ORG_FLAGS=01500000000000000000000000000000
Cache-Control: public, max-age=7200
Access-Control-Allow-Origin: *
DAAP-Server: iTunes/11.0.5 (OS X)
Content-Length: 7497842

mp3_webdav_offline_respone_header_without_proxy_plays_track_in_chrome

http://192.168.0.32:39371/5307b30c7765e9327243dafcfad46d68/%2Fstorage%2FEF9C-68FF%2FAndroid%2Fdata%2Fapp.symfonik.music.player%2Ffiles%2FOfflineMedias%2F2%2F2856E953F624F9367CB24B96B7510FC4.mp3
HTTP/1.0 200 OK
Content-Type: audio/mpeg
Date: Thu, 2 Jan 2025 18:51:57 GMT
Accept-Ranges: bytes
ContentFeatures.DLNA.ORG: DLNA.ORG_PN=MP3;DLNA.ORG_OP=01;DLNA.ORG_CI=0;DLNA.ORG_FLAGS=01500000000000000000000000000000
Cache-Control: public, max-age=7200
Access-Control-Allow-Origin: *
DAAP-Server: iTunes/11.0.5 (OS X)
Content-Length: 7497842

mp3_webdav_online_respone_header_with_proxy_downloads_track

http://192.168.0.32:41141/294a322c56743398888a8d503cd0aeeb/https%3A%2F%2Fnx39171.your-storageshare.de%3A443%2Fremote.php%2Fdav%2Ffiles%2Fgamebeaker%2FMusik%2Ftest%2FSingle%2520-%2520Hello%2520Jupiter%2FBored%2520to%2520Death.mp3
HTTP/1.0 200 OK
date: Thu, 02 Jan 2025 19:17:23 GMT
x-request-id: vgriwcAI4PJmc5kR6UdJ
server: openresty
content-length: 7497842
oc-etag: “f2fac6bd72a7157d3ed33e81e0b1a137”
x-frame-options: SAMEORIGIN
x-download-options: noopen
x-permitted-cross-domain-policies: none
strict-transport-security: max-age=63072000; includeSubDomains; preload
oc-checksum: SHA1:2deae45ee99c08d849ff666fc11cd788716f0e86
set-cookie: cookie_test=test; expires=Thu, 02 Jan 2025 20:17:23 GMT; Max-Age=3600
last-modified: Thu, 02 Jan 2025 18:32:44 GMT
content-security-policy: default-src ‘none’;
content-disposition: attachment; filename*=UTF-8’'Bored%20to%20Death.mp3; filename=“Bored%20to%20Death.mp3”
x-content-type-options: nosniff
x-xss-protection: 1; mode=block
x-robots-tag: noindex, nofollow
referrer-policy: no-referrer
x-debug-token: vgriwcAI4PJmc5kR6UdJ
content-type: audio/mpeg
etag: “f2fac6bd72a7157d3ed33e81e0b1a137”

mp3_webdav_online_respone_header_without_proxy_downloads_track

http://192.168.0.32:39371/5307b30c7765e9327243dafcfad46d68/%2Fstorage%2FEF9C-68FF%2FAndroid%2Fdata%2Fapp.symfonik.music.player%2Ffiles%2FOfflineMedias%2F2%2F2856E953F624F9367CB24B96B7510FC4.mp3
HTTP/1.0 200 OK
date: Thu, 02 Jan 2025 18:59:57 GMT
x-request-id: 1YfSJQ9vF4xmy6ZilJdO
server: openresty
content-length: 7497842
oc-etag: “f2fac6bd72a7157d3ed33e81e0b1a137”
x-frame-options: SAMEORIGIN
x-download-options: noopen
x-permitted-cross-domain-policies: none
strict-transport-security: max-age=63072000; includeSubDomains; preload
oc-checksum: SHA1:2deae45ee99c08d849ff666fc11cd788716f0e86
set-cookie: cookie_test=test; expires=Thu, 02 Jan 2025 19:59:57 GMT; Max-Age=3600
last-modified: Thu, 02 Jan 2025 18:32:44 GMT
content-security-policy: default-src ‘none’;
content-disposition: attachment; filename*=UTF-8’'Bored%20to%20Death.mp3; filename=“Bored%20to%20Death.mp3”
x-content-type-options: nosniff
x-xss-protection: 1; mode=block
x-robots-tag: noindex, nofollow
referrer-policy: no-referrer
x-debug-token: 1YfSJQ9vF4xmy6ZilJdO
content-type: audio/mpeg
etag: “f2fac6bd72a7157d3ed33e81e0b1a137”

opus_local_respone_header_with_proxy_plays_track_in_chrome

http://192.168.0.32:41141/ab4345353db84acc1c83e2b706137fff/primary%3ADownload%2FAlbum%20-%20Hello%20Jupiter%2FBored%20to%20Death.opus
HTTP/1.0 200 OK
Content-Type: audio/ogg
Date: Thu, 2 Jan 2025 19:15:46 GMT
Accept-Ranges: bytes
ContentFeatures.DLNA.ORG: DLNA.ORG_OP=01;DLNA.ORG_CI=0;DLNA.ORG_FLAGS=01500000000000000000000000000000
Cache-Control: public, max-age=7200
Access-Control-Allow-Origin: *
DAAP-Server: iTunes/11.0.5 (OS X)
Content-Length: 3780172

opus_local_respone_header_without_proxy_plays_track_in_chrome

http://192.168.0.32:39371/ab4345353db84acc1c83e2b706137fff/primary%3ADownload%2FAlbum%20-%20Hello%20Jupiter%2FBored%20to%20Death.opus
HTTP/1.0 200 OK
Content-Type: audio/ogg
Date: Thu, 2 Jan 2025 18:47:31 GMT
Accept-Ranges: bytes
ContentFeatures.DLNA.ORG: DLNA.ORG_OP=01;DLNA.ORG_CI=0;DLNA.ORG_FLAGS=01500000000000000000000000000000
Cache-Control: public, max-age=7200
Access-Control-Allow-Origin: *
DAAP-Server: iTunes/11.0.5 (OS X)
Content-Length: 3780172

opus_webdav_offline_respone_header_with_proxy_plays_track_in_chrome

http://192.168.0.32:41141/323fbc67dd1ff240bc8183d9992d67eb/%2Fstorage%2FEF9C-68FF%2FAndroid%2Fdata%2Fapp.symfonik.music.player%2Ffiles%2FOfflineMedias%2FC%2FCC637E6900D5C8A157ED5CB2F808EC56.opus
HTTP/1.0 200 OK
Content-Type: audio/ogg
Date: Thu, 2 Jan 2025 19:19:08 GMT
Accept-Ranges: bytes
ContentFeatures.DLNA.ORG: DLNA.ORG_OP=01;DLNA.ORG_CI=0;DLNA.ORG_FLAGS=01500000000000000000000000000000
Cache-Control: public, max-age=7200
Access-Control-Allow-Origin: *
DAAP-Server: iTunes/11.0.5 (OS X)
Content-Length: 4266763

opus_webdav_offline_respone_header_without_proxy_plays_track_in_chrome

http://192.168.0.32:39371/323fbc67dd1ff240bc8183d9992d67eb/%2Fstorage%2FEF9C-68FF%2FAndroid%2Fdata%2Fapp.symfonik.music.player%2Ffiles%2FOfflineMedias%2FC%2FCC637E6900D5C8A157ED5CB2F808EC56.opus
HTTP/1.0 200 OK
Content-Type: audio/ogg
Date: Thu, 2 Jan 2025 18:49:14 GMT
Accept-Ranges: bytes
ContentFeatures.DLNA.ORG: DLNA.ORG_OP=01;DLNA.ORG_CI=0;DLNA.ORG_FLAGS=01500000000000000000000000000000
Cache-Control: public, max-age=7200
Access-Control-Allow-Origin: *
DAAP-Server: iTunes/11.0.5 (OS X)
Content-Length: 4266763

headers where seek doesn’t work:

opus_webdav_online_respone_header_with_proxy_downloads_track

http://192.168.0.32:41141/98478d228cfb45d37fb3621320eef2cb/https%3A%2F%2Fnx39171.your-storageshare.de%3A443%2Fremote.php%2Fdav%2Ffiles%2Fgamebeaker%2FMusik%2Ftest%2FSingle%2520-%2520Hello%2520Jupiter%2FBored%2520to%2520Death.opus
HTTP/1.0 200 OK
date: Thu, 02 Jan 2025 19:16:26 GMT
x-request-id: f42VsGJxogOr0gQdc6em
server: openresty
content-length: 4266763
oc-etag: “ccccc896c1e895b1d0291263c31b47f5”
x-frame-options: SAMEORIGIN
x-download-options: noopen
x-permitted-cross-domain-policies: none
strict-transport-security: max-age=63072000; includeSubDomains; preload
set-cookie: cookie_test=test; expires=Thu, 02 Jan 2025 20:16:26 GMT; Max-Age=3600
last-modified: Thu, 02 Jan 2025 18:34:07 GMT
content-security-policy: default-src ‘none’;
content-disposition: attachment; filename*=UTF-8’'Bored%20to%20Death.opus; filename=“Bored%20to%20Death.opus”
x-content-type-options: nosniff
x-xss-protection: 1; mode=block
x-robots-tag: noindex, nofollow
referrer-policy: no-referrer
x-debug-token: f42VsGJxogOr0gQdc6em
content-type: audio/ogg
etag: “ccccc896c1e895b1d0291263c31b47f5”

opus_webdav_online_respone_header_without_proxy_downloads_track

http://192.168.0.32:39371/98478d228cfb45d37fb3621320eef2cb/https%3A%2F%2Fnx39171.your-storageshare.de%3A443%2Fremote.php%2Fdav%2Ffiles%2Fgamebeaker%2FMusik%2Ftest%2FSingle%2520-%2520Hello%2520Jupiter%2FBored%2520to%2520Death.opus
HTTP/1.0 200 OK
date: Thu, 02 Jan 2025 18:57:13 GMT
x-request-id: Jov60l2BmMlHyozMgwAp
server: openresty
content-length: 4266763
oc-etag: “ccccc896c1e895b1d0291263c31b47f5”
x-frame-options: SAMEORIGIN
x-download-options: noopen
x-permitted-cross-domain-policies: none
strict-transport-security: max-age=63072000; includeSubDomains; preload
set-cookie: cookie_test=test; expires=Thu, 02 Jan 2025 19:57:13 GMT; Max-Age=3600
last-modified: Thu, 02 Jan 2025 18:34:07 GMT
content-security-policy: default-src ‘none’;
content-disposition: attachment; filename*=UTF-8’'Bored%20to%20Death.opus; filename=“Bored%20to%20Death.opus”
x-content-type-options: nosniff
x-xss-protection: 1; mode=block
x-robots-tag: noindex, nofollow
referrer-policy: no-referrer
x-debug-token: Jov60l2BmMlHyozMgwAp
content-type: audio/ogg
etag: “ccccc896c1e895b1d0291263c31b47f5”

I don’t see a difference between the headers proxy enabled/disabled.

As said previously, proxy does not change the headers so it’s normal there’s no difference. So stop using that option it’s completely useless in both cases (Local and Webdav)

The difference is between Webdav server and Symfonium server.
But since you probably don’t have any choice on the Webdav headers, you need to see with the client side why it does not support seek with those headers.

My solution is that i use the nextcloud app and “sync”/download my music library. In symfonium i use the local provider.