v1.4.12
Fixes for 1.4.11: YouTube downloads, tracks skipping on their own, light mode, and local file playback.
Seven problems were reported within a day of 1.4.11. Four of them came from the same place — fixes in that release that were right in principle and wrong at the edges. Each one below was reproduced against the live services before it was changed.
The app now asks for music access
Opening a file through "Open with" technically needs no permission — the system grants access to that one file. 1.4.11 relied on that and asked for nothing, which was surprising: every other music player asks, and without it there is no way to tell whether the app may touch your music at all. It now asks once, requesting the right permission for your Android version, and points you at Settings if it was permanently denied. Refusing does not block a file you explicitly opened.
YouTube downloads still failed
1.4.11 added a memory of refused videos so the app would stop asking YouTube the same question repeatedly. It remembered too much: one entry per video, held for eight minutes, checked before any network call. A download started shortly after a failed play never reached YouTube at all — it was refused from memory. Re-measured this morning: the newer client identities answer normally for the very same videos the older one refuses, so a refusal is about one identity at one moment, never about the song. The app now remembers only which identity was turned away, for two minutes, and always tries at least one for real.
Songs skipped on their own
When audio could not be resolved, the internal audio server closed the connection without answering. To the playback engine a silent disconnection on a queued track means "this one is broken, move on", so it advanced — sometimes through several songs in a row. It now returns a proper error for that track, and a playback failure pauses on the song that failed instead of racing ahead.
Light mode was unreadable in places
The app was built dark-only, so around a hundred and ninety places named white or near-black directly instead of asking the theme. Those are invisible on a light background. Every screen outside the player now takes its colours from the active theme; the player keeps white because it sits on album art in both themes. A test now reads the source and fails the build if a hardcoded colour comes back.
Artists on YouTube tracks looked missing
The names were being read correctly — verified end to end from the live response through to the player. What was broken was the tap: opening an artist required a catalogue token, and a YouTube track carries a channel id instead, so on exactly those songs the artist appeared to lead nowhere. Tapping now falls back to searching the catalogue by name.
Local files showed 0:01 / 0:01
A file opened from a file manager arrives as a content link with no readable tags, so its length came through as zero and the progress bar drew a one-second track while the music played on underneath. The length is now measured with the decoder that will actually play the file, and the player republishes the real duration as soon as it knows it. Also fixed: tag lengths can simply be wrong — one test file reported 108 seconds for 95 seconds of audio — so the decoder is trusted over the tag.
Local files were poorly identified
Without tags the whole filename became the title, track numbers and all. Names now split on the usual conventions: a leading track number is dropped, "Artist - Title" fills in both fields, and download-site suffixes are removed.
Good to know
- Build 30. If you are on 1.4.11 the update prompt will appear as usual.