awesompd icon indicating copy to clipboard operation
awesompd copied to clipboard

Use `mpc idle` instead of polling

Open Ram-Z opened this issue 10 years ago • 3 comments

Would it be possible to use mpc idle or mpc idleloop to update the status instead of polling it every update_interval?

The idea is to reduce the number of useless connections created to mpd. Connections would only needed to be made when something has actually changed on the mpd side and to get the current time when the mouse hovers over the widget.

I could even have a look at it myself, if I find a way to execute functions when mpc idleloop has new output.

Ram-Z avatar Jul 23 '14 14:07 Ram-Z

I don't have enough time to do it now, but you are welcome to try.

If you were to implement this you'd probably have to use asyncshell.lua to avoid locking whole Awesome while the code awaits for shell command to complete. For the same reason idleloop wouldn't probably fit as it never completes.

On a sidenote, I have some uncommitted changes with on-screen widget. That code obviously requires constant polling as widget stays on the screen permanently. So I'm not sure in the end this implementation will fit all the usecases.

alexander-yakushev avatar Jul 23 '14 15:07 alexander-yakushev

I saw this within an hour of merging. If your still interested, I seem to have working code, though it could use a look over from someone who knows what asyncshell.lua is doing. I also added recalculate_track, track_update_time, calc_track_passed, and calc_track_progress. Which use difference in os.time to calculate the current track position and progress, probably the main reason for constant polling. If their isn't a problem using async (like perl and ithreads, which must be compiled in), it may be a better option than smart_update (catches changes from other mpd clients instantly, automatic mpd track change as well). (I've exhausted all forms of entertainment other than listening to music, coding, and blogging in comments/commits)

firefish5000 avatar Jul 25 '15 01:07 firefish5000

I didnt mean to reference this in the first commit. (didn't know I could) I'm still testing it, but it seems to work rather well. And I believe the relative code is smaller than smart_update.

Recalculate_track currently sets 'calc_' prefixed vars, meaning non calc_ ones wont using this functionality. Made this while working with the onscreen widget version. Some status_text related things got included since removal looked time-consuming. (wondering why your holding it back, its great! Updates without flickering! if it had ontop =true and x/y pos set relative to mouse on the text widgets mouse::enter event, it may even double as a beautiful notify. )

You may want to bump update_interval up, I set mine to 60 since it shouldn't be necessary(except for syncing time in case mpd plays faster/slower than os.time, which should take a while to be noticeable).

It shouldn't hurt to change mouse::enter's update_track to a recalculate_track and set notify_track to use calc_track time and pos. Though having fallback may be a good idea. (I think I'm avoiding writing my English paper the wrong way)

Let me know if your interested in any of it, have suggestions or complaints.

firefish5000 avatar Jul 25 '15 03:07 firefish5000