Recent changes to bugs

#52 'Keep Wi-Fi active' not working if stream format is mp3

AussieFries — Tue, 11 Aug 2015 07:46:07 -0000

Could someone please look into this?

'Keep Wi-Fi active' not working if stream format is mp3

AussieFries — Thu, 21 May 2015 11:59:08 -0000

Radio stream stops playing when screen turns off, even though 'Keep Wi-Fi active' is activated.
This only happens if the stream format is mp3. (I know this sounds bizarre).
Problem can be replicated with following URL.
http://94.125.94.22:8000/radio?.mp3
Issue happens even though Android Wi-Fi sleep policy is set to 'Never'.

Many thanks for looking into this!

Replaying old crap after connection problem

Oxy — Mon, 18 May 2015 08:44:41 -0000

After connection problems ServeStream sometimes goes to stop. Now when user presses the play-button to reconnect ot the stream, it starts playing very old data (once they have been received more than 20 minutes before). Only solution: kill the application completely and restart it again.

Same happens when application is started later again with the same stream, it states "connecting to URL#..." but then comes up with old data - once I could hear the morning show again - in the afternoon. Here also only killing the app via android settings helps.

Start with bluetooth not responding

Jorn Janssen — Fri, 08 May 2015 19:43:08 -0000

On my Samsung Galaxy S4 running Android 5.0.1

The option in ServeStream 0.7 to 'Auto start with bluetooth' cannot be enabled it simply won't change state and doesn't seem to show or do anything. Looking forward to use this function! (thanks for this great app)

#49 "stop" vs "pause"

Nikita Smirnov — Wed, 06 May 2015 11:22:07 -0000

It is worth noting that in case of a poor internet connection when ServeStream stops playback then it is almost always unable to continue it until it's manually stopped and restarted. And when I say "stopped" I mean exactly stopped by using "Stop" button which is hidden in a submenu, while "Pause" button placed on every control panel is completely useless in this case.

Again, when playback is hanged because of a poor internet connection, the only way to restart it is by using the only "Stop" button. Nothing else works in that case. And the "Stop" button is located in VERY inconvenient place.

I won't however complain more and ask for fixing things ASAP as I finally remembered the name of the app I used on the old phone for internet radios (Xiia Live if anyone's interested), which works A WAY BETTER when it comes to unstable mobile connection and buffering things. At least it is able to restart the playback itself. And buffering there is actually working.

"stop" vs "pause"

Nikita Smirnov — Mon, 27 Apr 2015 12:09:33 -0000

Currently this app suggests the user to use the "pause" button as default control to stop the playback as it is visible by default in all player control menus. However pressing this button results in playback being, well, paused, while the app continues downloading a music stream to some buffer in the background for an undefined time. Which is obviously not the intuitive behavior (and could cost someone some unexpected money for mobile data plan as someone noted in the recent Google.Play review).

I know there's a way to unambiguously stop the playback with the "stop" button, but it is located in a submenu at the main playback screen, and also not present within notification area player buttons. So using this control as main "stop" button is quiet inconvenient because of that.

I'd suggest to add an option to replace "pause" button with "stop" button so the user could choose whether it's ok for him to pause stream while the app will continue to download a media-stream, or would he prefer to always completely stop the playback without any further background actions.

Another solution is to add an option which would define for how long the app will continue background media-stream downloading when the playback is paused, with an ability to also select zero value which would mean that "pause" button action should be equal to "stop" button action.

#48 New bugs in v7.0.

William Seemann — Sun, 08 Feb 2015 04:16:22 -0000

status: open --> closed

#48 New bugs in v7.0.

William Seemann — Sun, 08 Feb 2015 04:16:06 -0000

I'm sorry the new version has some regressions. As the app evolves these things happen. Regarding your issues:

NEW. Cannot edit stations - Fixed, available in next release
NEW. The "Order" feature has gone - No it isn't, it's now part of the main list functionality
NEW. I see that one now has the option - Fixed in next release
Fairly NEW. The "Last Connected Date" is broken - Nope, it isn't.

Regarding the backup format - While XML may be easier for you to read and edit JSON is easier to parse, hence my decision to use it.

New bugs in v7.0.

Mr Goose — Sun, 14 Dec 2014 01:25:20 -0000

I love Servestream, I really do. But sadly this latest version 0.7 has a number of rather annoying NEW bugs/regressions, some of which are on the verge of becoming deal-breakers:-

NEW. Cannot edit stations. The dialog that pops up is blank and any text you enter is ignored. Any mistakes one makes entering a station can no longer be corrected and one has to delete the station and start again. The only workaround appears to be export all the stations as "backup.json", edit this in a text editor and then reimport it! What a pain!

NEW. The "Order" feature has gone! Granted it never worked properly, but at least it provided a quick way to delete stations. This was useful for deleting stations prior to importing a from "backup.json" file. Otherwise duplicates can occur.

NEW. I see that one now has the option to use a "long press" to select more than one station on the URL's screen. Presumably this is advance work for new features? Anyway, if one does select more than one station, then Servestream instantly crashes.

Fairly NEW. The "Last Connected Date" is broken. Actually, I think this was broken in the last released version. It no longer displays the date that the connection to the station took place. This is relatively trivial and I'm sorry I did not note when it this was broken.

Final question: why did you decide that the backup file should use a json format anyway? XML would be much, much easier to read and edit manually!

(Ainol AXI Numy 3G, Android 4.2.1, Kernel 3.4.5)

New bugs in v7.0.

Mr Goose — Sun, 14 Dec 2014 01:25:20 -0000

Ticket 48 has been modified: New bugs in v7.0.
Edited By: William Seemann (wseemann)
Status updated: u'open' => u'closed'