Page 4 of 7 FirstFirst 1234567 LastLast
Results 61 to 80 of 121
  1. #61  
    Quote Originally Posted by Daemon View Post
    I've got a little different feature request.

    How about a sleep timer? I often fire up a streaming station
    to help me go to sleep. It's very effective. The problem is of course
    that if I leave it streaming, it sucks the battery down. And due
    to the bug in the Pre's streaming api, even if I wake up long enough
    to just stop the stream, it still sucks the battery dry while idling (same as
    Pandora). I even tried doing a back swipe to jump back to station list,
    but idling there it still pulls the battery down (that may be a bug you
    can address).

    What I really want though, is simply the ability to tell it to
    stream for 20-30 minutes and then have the app close itself completely.

    ian
    Add me to this wish list too. +1
  2. Daemon's Avatar
    Posts
    796 Posts
    Global Posts
    809 Global Posts
    #62  
    Quote Originally Posted by scheumanrj View Post
    Add me to this wish list too. +1
    Still want this feature, but for now I've found a workaround.
    I've installed the Battery Saver HB app which can put the phone into
    and out of Airplane Mode on a schedule. I've found that simply shutting
    the radio off while a streaming app is running, not only kills the stream,
    but prevents the streaming API from doing whatever nasty thing it
    normally does while idling that sucks the battery down.
    I just set the schedule to go to airplane mode about 30 minutes after
    I start streaming, and go ahead and let it stay off till 6:30 am or so.
    You can however set it to only shut off for a few minutes and the streaming
    app will stay in low-current zombie mode indefinitely.


    ian
  3. #63  
    Just discovering Shoutcast stations, and maybe someone here can clear something up for me. Is there any difference (under the covers) in using a Shoutcast app as opposed to just pointing your browser at a URL for a Shoutcast stream (and having the WebOS player pop up).

    I mean, I understand the advantage of having all the stations managed and remembered for you, but if I just have one or two that I like, and can bookmark them in the browser ... then that's essentially the same thing, right? There's no buffering going on in the apps (which would be really nice while you were in the car) or any other sound enhancements?
  4. Daemon's Avatar
    Posts
    796 Posts
    Global Posts
    809 Global Posts
    #64  
    They're functionally equivalent once you start streaming.
    One thing I've noticed though, is that while the names of most
    stations stay the same, sometimes the actual hostname or IP
    that you connect to to reach it may change, which means it's
    nice to have an app that can do a quick search to find the station
    again.

    ian
  5. ieko's Avatar
    Posts
    354 Posts
    Global Posts
    361 Global Posts
    #65  
    I've always wanted a streaming app smart enough to choose a stream based on the network.

    For example, say I have two identical stations on my playlist but they both have different bitrates, one being 24kbps and the other being 80kbps. Now lets say I'm listening to the 80kbps stream through 3G/EVDO and suddenly my signal goes to EDGE/1xRTT. Obviously I'm going to lose my stream, but wouldn't it be great if the stations were somehow grouped and the player noticed the network change and chose the 24kbps stream until 3G/EVDO came back?
  6. #66  
    Quote Originally Posted by vanadium View Post
    This shouldn't be happening anymore. I've been running battery burn tests and after swiping back to a list, the entire Audio() object now shuts down--and I mean completely down. So at this point it shouldn't be sucking any more battery in list modes than any other app that responsibly handles its services API objects.
    It may not hapen when you swip back to a list view but it burns the battery and gets hot if you just pause the stream and forget about it.
  7. Daemon's Avatar
    Posts
    796 Posts
    Global Posts
    809 Global Posts
    #67  
    Cept you can't really pause a shoutcast stream anyway, so why not
    just turn the pause button into a stop button and have it kill the
    Audio() object? Or do you not control the code behind the buttons in
    the player? Same if you unplug the headphone jack. That's the
    one that always gets me. Stream in the car, get home, pull the phone and
    hand full of other stuff out of the car and forget to kill the audio streaming
    app. Don't notice until my arm brushes across the phone a half hour later
    and find it hot as hell, and battery down 20%.

    ian
    Last edited by Daemon; 10/10/2009 at 10:08 PM.
  8. ksom's Avatar
    Posts
    355 Posts
    Global Posts
    358 Global Posts
    #68  
    Quote Originally Posted by vanadium View Post
    ksom should be happy about this one.

    FINISHED: Fixed issue with hanging Audio() object on erratically-buffering stations.
    FINISHED: Big performance boosts throughout the application during casual use.

    0.9.05 submitted.
    Thank you, I already downloaded the latest version. Great work.
  9. #69  
    Just wanted to pop in and say the previous version had been working flawlessly for me, though I had only been using it lightly. I just downloaded the latest version and have it playing now... it's working fine so far. Thank you for the fine program.
  10. Daemon's Avatar
    Posts
    796 Posts
    Global Posts
    809 Global Posts
    #70  
    Quote Originally Posted by vanadium View Post
    Ok, Daemon, I've done some code refactoring in the player and I'm pretty sure I've implemented what you're looking for. I've ditched using 'pause' for a full disconnection from the stream, which should solve your problems. It adds a couple of seconds when you go to resume play due to reconnecting and rebuffering the stream, but I find it negligible after the improvements Palm made to Audio()'s stream handling in 1.2.1.
    Sounds good. Seems a reasonable tradeoff to me. Thanks.

    Quote Originally Posted by vanadium View Post
    I've added my *very* last feature, which is in testing for the next hour or two: a play duration timer.
    Oh drat. Got me excited for a minute there. I thought you were talking about a sleep
    timer (set it to play for XX minutes and then shut off), but it's just a counter.

    ian
    Last edited by Daemon; 10/10/2009 at 10:10 PM.
  11. Daemon's Avatar
    Posts
    796 Posts
    Global Posts
    809 Global Posts
    #71  
    Testing the Stop functionality, and not seeing a difference from before.
    I started the battery monitor. Nothing else running
    but Shoutcast 0.9.40. Started a stream, hit Stop and let it sit.

    Battery monitor is reporting 27%/hour drain, pulling 300-359mA continuously.
    Phone is hot too. I thought maybe I had some other zombie process
    running, so I went ahead and rebooted the phone, and ran the test
    again, and am seeing exactly the same results.

    Normally with one or more idle non-streaming apps running, I see less than 4%/hr drain
    at around 5mA.

    ian
  12. Daemon's Avatar
    Posts
    796 Posts
    Global Posts
    809 Global Posts
    #72  
    To do near-realtime monitoring with BM, best is to knock the interval down to 1 minute
    and then let it run for a few minutes with the screen/keyboard off to get a baseline,
    check the instantaneous stats for current draw. Then back out to the BM
    start screen (without exiting the app) and restart the monitoring every time
    you try something different.

    I charged the phone to 100% and tested again, and it was still sucking
    it down at 25-30% per hour (300-400mA) while idling and 60%/hr (650mA)
    while streaming (which I think is higher than it was in previous versions)

    As for the latter, I remember seeing in a different app was that anything
    that continuously updates the display sucks Luna CPU time (thus battery
    as well) pretty hard. In this case, I'm talking about the new running timer.
    I was just doing some more testing, and realized that with the battery at
    89%, streaming a 24kbps AAC+ station that I listen to all the time,
    with the phone plugged in to home wall charger, it was not able to
    charge the battery. Just hung at 89%. Pretty sure that's the first time
    I've seen that, and I'm guessing the continuous update of the timer has
    pushed it to the break even point.

    If I could downgrade to the previous version I'd re-test, but I don't have
    a copy of that ipk.

    ian
  13. #73  
    This is the best shoutcast app for the Palm Pre! However, it just me or whenever a station stops responding it automatically skips to the next available station. Is this a bug or a feature? It think it should retry to play the same station again. Also the playing status doesn't always mean that is playing... Regarding buffering, could that be improved? I've noticed while playing it doesn't seem to buffer good enough. I'm compering it to Pandora which does an excellent job at buffering. Also DrPodder is a good example of network connection. It shows 4 states: connecting, buffering, playing and stopped and I don't see the buffering status on the shoutcast app. Even as it is I love this app! Thank You
  14. Daemon's Avatar
    Posts
    796 Posts
    Global Posts
    809 Global Posts
    #74  
    Well, all I can say is that it's now sucking down the battery faster than
    I've ever seen before. I've restarted the phone twice, and retested from
    scratch. Baseline with nothing else running and display off is 3-5mA draw.
    Shoutcast idling after a stop (300-400mA) and streaming almost double that.

    If you can make one of the earlier ipks available somewhere I can retest with that.

    ian
  15. Daemon's Avatar
    Posts
    796 Posts
    Global Posts
    809 Global Posts
    #75  
    Thanks. testing .35 right now.
    Baseline -5mA (screen/keyboard/GPS off, shoutcast not running) (20 min)
    streaming -309mA (20 min)
    Stopped... -309mA (10 min)
    Re-started stopped stream - 500-650mA (5 min)
    Stopped again - 330-500mA (5 min)


    I think that's consistent with the odd results I saw last night.
    The super high current was after I'd restarted a stream. Didn't
    realize that until today though. It's as though whatever eats
    current while it's idling is still running as a separate thread
    after the stream restarts.

    My battery is under 20% so I'm going to have to recharge before retesting.

    ian
  16. Daemon's Avatar
    Posts
    796 Posts
    Global Posts
    809 Global Posts
    #76  
    Noticed a nasty bug in .35 that appears to have been fixed in .40.
    If you play, then go back one screen (without stopping) and play
    again, it plays the stream twice. Do it again.. 3 times etc.. all at once
    with a small echo between them.

    Back to testing .40.
    Using 1 minute sampling interval and turning screen off as much
    as possible, waking up every few minutes to check current draw
    in detailed stats. Re-"start monitor" for each test cycle but without
    closing BM app.
    %/hr takes a while to stabilize for each cycle but is consistent with
    instantaneous mA values.
    baseline -3 to -4mA (steady)
    normal play -305mA -309, -310
    stopped -336, -322, -309,
    play again after stopped -546, -497, -573, -512
    back one screen from there to stop stream -396, -362, -360 -359
    start same station again -515, -530
    close shoutcast app - back to baseline draw

    Basically whatever causes it to burn cpu/battery while idling
    appears to get added to playback when stream is restarted
    because stop and restart is always higher than first play.

    ian
  17. Daemon's Avatar
    Posts
    796 Posts
    Global Posts
    809 Global Posts
    #77  
    Just completed some battery monitoring on Pandora, and verified something
    I had long suspected. It burns more battery when it's paused
    than when it's actually streaming.
    Streaming - 120-135mA draw, and quite steady regardless of whether it was in the
    middle of a song (well buffered) or starting a new song.
    Paused - 295-350mA (which I suspect is pretty much the same
    across all streaming apps when they're paused).
    Sure wish Palm would fix this stupid bug in the API.

    I also notice that when you switch tasks away from Pandora (or minimize window)
    and come back again, the track counter disappears and reappears.
    It's only visible and updating when Pandora is active. I was wondering if
    maybe they were doing it to avoid expensive Lunu UI updates (per the hypothesis I
    mentioned earlier), so I tracked down a shoutcast version that has no
    UI updates while it's playing (no animations, no counter) and it still uses
    over 350mA while streaming. So, I dunno.

    ian
    Last edited by Daemon; 10/12/2009 at 03:19 AM.
  18. #78  
    Just wanted to drop a quick post. I was flipping through some stations quickly to add some favorites that I had lost during the upgrade. After a short while, the Pre gave me a "critical memory" error, and said too many cards open. Shoutcast was the only open card! I think I hit a memory leak somehow. I logged into the terminal and ran top, my resources were hit pretty hard, CPU on that one process was around 97% just at the main menu of shoutcast, and as I said before, almost all available memory. I wish I had more info to give you, but there's definitely a problem somewhere.

    That said, I rebooted and all was fine. I imagine I triggered it jumping back & forth, stopping & starting, etc. I love your app though, great work so far!
  19. kingle1's Avatar
    Posts
    33 Posts
    Global Posts
    35 Global Posts
    #79  
    Vanadium:
    Love the app, but having a problem. At first, I could not listen to my favorite station (WBAP-AM) even though it was on Shoutcast's list. A couple of versions ago, I was able to listen to the station, but another that I was using (WWGE) broke. Now, at 9.4, I'm right back where I was -- WWGE works but WBAP does not. I get a message in the "Currently Playing" section of the screen that says, [play|. The counter comes up, the Ev light comes on, but there's never a sound. (This is what WWGE did at the last change, but now it works correctly.)

    Any help you can provide would be greatly appreciated.
  20. Daemon's Avatar
    Posts
    796 Posts
    Global Posts
    809 Global Posts
    #80  
    Try searching for the station again.
    Shoutcast hosts come and go and you may get
    that behavior when you try one that's moved to
    a different host.

    ian
Page 4 of 7 FirstFirst 1234567 LastLast

Posting Permissions