SubFire Known Issues - 0.5.0 - 1.4.6.0
One of the drawbacks of using the HTML5 audio tag is that, like the classic days of the 90s browser wars (I fought in those, too), things are ever so slightly different on each platform. In an ideal world (currently that is just Chrome for the Desktop), everything would work according to the standards. Unfortunately, that's not the case.
FireOS 5 for TV/Stick: A change in how it handles back-button and menu events from the remote has broken the current version. I have managed to work around them and submitted a new update which should roll out by the end of today, and am in discussion with Amazon's forum to determine if this is permanent or temporary. The bugs you will see are that 1) the "back" button goes back 2 screens instead of one, which can frustratingly exit the app, and 2) the menu button doesn't work and you have to use the remote to get up to the config screen's button.
Chrome 40-48 for Android: Chrome 38 actually worked just fine on my tablet, but Chrome 40+ does not. The Bug is that it plays just fine, but never actually updates the "current time". At this point, I've not played a track long enough to know if it will actually 'next' correctly at the end or not. This behavior also is inconsistent. Earlier today, everything was fine, but tonight it was back to not responding. The bug is still there in the Chrome/Android engine, and only appears for CBR (constant bit rate) files. Variable bit rate files like those from Amazon and Google Play worked fine. I wasn't worried about it 'til FireOS upgraded to a Chrome 41 based browser engine for their 5.1.1 platform, and suddenly it was broken, too. As such, I gave it a go and managed to fix some earlier hackery. It is still a hacky workaround but it is at least functional now. It may break down if your tablet has a weak connection to the server and stalls. The clock will continue to advance but no music will play. Because of the bug, i have no way to know that is actually happening.
FireOS 5 for TV/Stick is now at Chrome 41 and therefore has this same bug. I will at some point start experimenting with the Web Audio API to see if it handles things differently, now that it is supported on that platform.
Chrome 41 for OSX and "an error occurred": No idea how widespread this is, but at my work, the Chrome version will cut out playing, usually right around 1:10 into a track. It doesn't do this on Gecko browsers (Firefox/Thunderbird). At this point, it seems to just be my work network because if I pick up the building's guest wifi, it isn't a problem. But if I see it get more widespread, I may file a bug with Chrome to see what they can do about it (if anything). A workaround was found: the problem files were all variable bit rate (purchases from Amazon or Bandcamp). Turning on bitrate transcoding to 128 resolved this. This problem was actually distinct to only my work network, where our firewall randomly chooses times to change our IP address (in order to minimize back-hacking). Most of you will never run into this situation. In general, VBR files are better for SubFire, particularly on webkit/blink based browsers like Amazon and Chrome.
Amazon Fire TV and Stick: These are based on a slightly older version of webkit (possibly still attached to Apple's instead of Google's recent fork). The bug they have is one I was able to work around, but it sets limits on features I can support. What happens here is that the audio tag is not sending a 'range-accept' line to the server. This means the server is not able to send back a 'range' instruction, which means the audio tag is not able to actually determine the track's duration and figure out when it actually has reached the end. It also means that I have no ability to 'skip' through the track.
I wanted to support a 'skip 30 seconds / rewind 15 seconds' feature, similar to the plex apps, but to no avail. It is also why the progress bar is not draggable except in Chrome (as of 0.8.0). I was able to work around the hard part (not knowing if a song was over) by relying on the duration value sent by Subsonic itself in the API, but until this is upgraded, that's the most I can support in terms of controlling audio playback within a file.
With Fire upgrading its browser to one based on Chrome 41, it now has more access to the Web Audio API, so I may try things differently at some point in the future.
Back Button: There are times the back button can cause a "loading playlist undefined" dialog to show up that can't be gotten rid of. It appears to happen more often with artificial back buttons (e.g., the Backspace key, which is the 'B' button on game controllers), but i've triggered it with the back button on the Fire Stick remote. I'll fix this asap. Fixed in 0.5.2. Additional back-button fixes applied to browsing mode in 0.7.5.
Artist info: it doesn't always work right. Currently, it pull from the 'artist' for a song, but it does so by looking up the chain on the presumption that the hierarchy is Artist>Album>Song. If your artist or your album isn't quite in that kind of a format, you're likely to get no artist info content. There really isn't much I can do about that (limitation in the API). ID3 mode while in the album browser may work better in some cases.
Long idle time: If you pause it and leave it paused for a long time, resuming doesn't really work right and the only fix is to go back and forth to get it to start over. Not sure what to do here yet. Seems more a problem on Chrome than Fire, and it may be my corporate network that's the problem, forcing a disconnect of the signal. This turned out to be my office network: their firewall changes my outside IP address regularly, which causes disconnects with services like my subsonic server.
Firefox button sizes: When on a large (> 1441 px wide, including 1080p) screen, the text of Firefox increases appropriately, but the buttons do not. This is a CSS gap - Firefox does not support the 'zoom' instruction that webkit does. Not much I can do about that.
Fire sluggishness: Not sure if it is just a memory problem, but when I finally installed the app on my Fire Stick, it was a little sluggish in getting started and loading the playlists (and their icons), and actually being able to play. This resolved itself in time and things seem smooth now.
Chrome 40-48 on Android sluggishness: I'm not sure what's up. Everything is very fast, except actually playing the track. It just sits there for quite a bit before it plays. I really need to start looking at the loading events to see what is going on. This seems to primarily be an issue over phone networks. Over a wifi, things are fine.
Keyboard interaction in the new play queue screen can appear to 'empty' the queue. I'm still not sure what hiccup is causing this. Workaround is to just 'next' and it should reset to the first track.
Album grid doesn't handle resizes correctly. Chrome for Desktop and tablets (tv's can't resize). This is better, but I'd still like to tweak it more.
Play queue size isn't always reset when layout is changed (Chrome/Desktop). Fixed in 0.9.8.
Intially Empty Screen: There were issues getting the initialization to start correctly, conflicts between jquery's ready() and the cordova deviceReady events, which caused the initial playlist load to not happen. Fixed in 0.6.2.