Repository navigation
tracks= in teddycloud content api seems to be ignored leading to Downloaded ZIP archive (Tonie --> multiple ogg) cannot be opened by Windows Explorer #350
Description
ZIP archives created/downloaded by TeddyCloud can be reported as invalid by Windows Explorer.
Windows shows the following error when opening the downloaded archive:
The folder cannot be opened.
The ZIP-compressed folder is invalid.
Steps to reproduce
- Download a tonie using the new track download functionality from TeddyCloud that is provided as a ZIP archive.
- Save the generated ZIP file.
- Open the ZIP using the built-in Windows Explorer ZIP support.
Actual behavior
Windows refuses to open the archive and reports it as invalid.
Expected behavior
The generated ZIP archive should be standards-compliant and open correctly with the built-in ZIP support of Windows as well as other common ZIP tools.
Additional notes
The generated ZIP structure should be checked for compatibility with Windows' built-in ZIP implementation, especially:
- ZIP central directory / end-of-central-directory records
- file sizes and offsets
- compression method
- filename encoding
- data descriptors
- archive finalization before the download is completed
It would also be useful to verify the same generated archive with tools such as 7-Zip or unzip -t to determine whether the archive itself is malformed or whether a ZIP feature unsupported by Windows Explorer is being used.
Example file:
Traveltonie.zip
Activity
henryk86 commentedon Oct 16, 2026
@ditschi: You might have a look here.
Maybe this issues should be moved into the teddycloud repo
henryk86 commentedon Oct 16, 2026
the size of the zip with a few tracks only is equal to the size of the download of the whole tonie as ogg.
henryk86 commentedon Oct 16, 2026
Investigated some more... the zip file is actually the whole ogg, just named as zip. The API does not deliver the expected zip file when passing &tracks=2,3,4
ditschi commentedon Oct 16, 2026
interesting on my ubuntu machine in the docker testenv extracting the zip worked.
but maybe some rework broke something (i did only verify this once and as i did not change anything where i expected this to break i didn't repeat that verification.
I am currently building to verify this again. If this is a windows only issue then i can only ask the llm to suggest a fix but i won't manage to verify myself as i do not own ans machines running windows.
ditschi commentedon Oct 16, 2026
Thanks @henryk86 , the investigation helped.
Result on our side: we can’t reproduce this on Linux with current develop. On Ubuntu a manual download of a multi-track selection (…?ogg=true&tracks=2,3) returns a proper application/zip. unzip -t is clean, and extraction and playback of the tracks work. tracks=2 returns a single Ogg as expected, and the web client builds the URL the same way.
Your file: Traveltonie.zip starts with OggS, so it is the full Ogg stream, not a malformed zip. Windows is right to reject it. That matches your finding that tracks= was ignored.
Open question: which backend served that request? Are you sure teddycloud#484 (track export) was merged in the version used on your side. Could it be that the web UI and the teddycloud binary came from different builds? If you can, please check the build or commit of the exe or container that answered.
Separate Windows risk: the backend builds the zip by running an external zip binary (handler_api.c, osSpawnvp("zip", …)). That’s present in the Docker images, but a native Windows install might have no zip on PATH, so multi-track download would likely fail there. We haven’t been able to verify it on Windows yet.
Proposal: write the zip in-process. It would be store-only, since Ogg is already compressed, with no new dependency and about 100 lines including CRC32. It would work the same on all platforms. We’d add a test and have the windows-latest CI job start the exe and run it, because I personally have no Windows machine. Unless you’d prefer to keep zip as an external requirement and show a UI hint when it’s missing, we’ll go with the in-process version.
henryk86 commentedon Oct 17, 2026
i am running the current develop (pulled yesterday evening, now again without any change).
--> TeddyCloud vX.X.X (e5fac5c) - 2026-10-16 10:39:18 +0000 ubuntu linux-x86_64(64)
--> https://github.com/toniebox-reverse-engineering/teddycloud/tree/e5fac5ca1e27e7479438783f32193ec6fd02b25b
which contains:
the issue is not windows. the ubuntu server returns a ogg file ("500304E0" no file ending) if i call the api call manually. not the expected zip.
Maybe something else answers the request before the new function can answer it?
the complete call (copied from the network tab, removed specific data): https://ABC/content/download/A64E581D/500304E0?overlay=AAAAAAAAAAA&skip_header=true&ogg=true&tracks=10%2C11
If the web ui creates / uses a wrong link... please give me the right expected link. I modified the code around a bit: 0431fa4 (but the issue happens also on the unmodified teddycloud develop version)
Docker logs:
INFO |handler_cloud.c:0483:getTonieInfoForRequest()| >> client requested content for rUID a64e581d500304e0, auth 00000000...
INFO |handler_cloud.c:0758:handleCloudContentExt()| Serve local content from /teddycloud/data/library/taf/xxx/xxxxxxxxxxx.taf
[-]Downloaded ZIP archive (Tonie --> multiple ogg) cannot be opened by Windows Explorer[/-][+]tracks= in teddycloud content api seems to be ignored leading to Downloaded ZIP archive (Tonie --> multiple ogg) cannot be opened by Windows Explorer[/+]henryk86 commentedon Oct 17, 2026
I think i found the problem.
Its the place you do it.
(btw. the download of 500304E0.json files are now saved as oggs...)
henryk86 commentedon Oct 18, 2026
With the help of ChatGPT, I was able to fix the issues.
Issue 1: TonieInformationModal in the Content section (.../tonies/content) when opened for a 500304E0.json file
→ 6b6595c
Issue 2: TonieInformationModal in the Tonies overview
→ c82c70d
Issue 3: TonieInformationModal opened from the audio player
Track selection was not possible because selected tracks were reset on every re-render. The same also happened when the screen size changed.
→ ec0200d
Issue 4: 500304E0.json filedownload loads the json as ogg file
→ a29e265
Tested:
henryk86 commentedon Oct 18, 2026
@ditschi : maybe you can have a look into the changes above.
I found another bug with the taf splitting: toniebox-reverse-engineering/teddycloud#552
ditschi commentedon Oct 18, 2026
Thanks @henryk86, your debugging pinned it down. This is a backend bug, not Windows and not a build mismatch.
Cause: The download from a Tonie card or the info dialog uses the tag's
audioUrl, i.e./content/download/<ruid>?overlay=…&skip_header=true&ogg=true&tracks=10,11. Your log (handleCloudContentExt … Serve local content) shows that this route is served by the cloud content handler. It never looked attracks=and streamed the whole TAF as Ogg, which the client then saved under a.zipname. The File Browser route (/content/<file>.taf?special=library&ogg=true&tracks=…) does handletracks=. That is why it worked in the library and why I couldn't reproduce it earlier.Fix: toniebox-reverse-engineering/teddycloud#553.
/content/download/…now resolves the tag's source (e.g.lib://…) and uses the same track export as/content/…. A new test covers both routes with a tag pointing at a library TAF. It fails without the fix exactly as described here.Verified: With the fix, the tag's own
audioUrlplustracks=2,3returns a zip with the two selected tracks. I checked this in the web UI of #348 against a local build of the fix.Not covered, separate PRs:
zipbinary, so native Windows works). This should also fix the UTF-8 filenames from Track split ZIP corrupts filenames containing special characters teddycloud#552.Details on how this relates to the web changes are in the comment on #348.
Honor tracks= on /content/download for tag track export