Problems when using a remote to select ‘previous’

Help and Support
21

Well um, yes. Thanks for pointing that out! :face_with_hand_over_mouth:
Will make the changes a.s.a.p. (When the embarrassment wears off!)
Just wondering if it’s worth submitting a P.R. for the plugin the DVO suggested. I can’t see it being a ‘best seller’.

1 Like
22

The position is incorrect many times, i would rather parse the position myself by observing the queue and getState simultaneously. Queue seems to get updated by all the methods that can modify it, but this change does not mirror itself to playerState in terms of the position data it provides.

23

So you need to get uri from getState and then search for it in the response of getQueue for the true position? That sounds annoying.

PS: Given your recent experience(s) with the API, would be great if you pen down some thoughts for improvements. That would be really helpful for the devs when this pops back onto their radar!

24

strange thing is that the rest api is just running it fine, if i pull it in rainmeter
volumio can’t get it right in the player…
but getting a normal prev with rest api is a hell it just jumps to seek 0 instead of the song before.
dubble press doesn’t work and hangs if you do it to mutch.

25

I just went spelunking and found gold.

skipBackwards

var io = require('socket.io-client');
var socket = io.connect('http://localhost:3000');
socket.emit("skipBackwards"); // Skip track
//socket.emit("prev"); // Jump to track start
socket.disconnect();
26

Yes, comparing the Uri to queue items works 100% of the time, nothing else does not.

Perhaps the most easy way to reproduce is to move items on the queue couple of times and make sure to move the currently playing aswell, and try the “Go To Artist” or “go to Album” which i believe relies on the position returned by getState, it will go to wrong artist/album, now if any client requested getState at this time, the position is wrong. (this sometimes also leads to wrong track prefetched and played next)

There is also a proplem that getState seems to push atleast ~5 updates on track change, and only some of the data does have correct “position”, usually the last one is with correct position thought, but i would not rely that all the updates gets throught if the connections is acting weird for example, then you might get the wrong position, since you did not get the last packet at all.

it depends alot what you are doing with the position if its good enought or not.

27

i use it for controle of the music (play /pause, next ) and a seek bar and the data to show incl. the images and volume controle only prev doesn’t work. with a powershell script in rainmeter.
and a good showing of the time played and end time insteady of the stupid volumio way.

28

That will never work – the REST API’s cmd=prev will end up calling previous. As I understand it, it will always reset to the start of the track.

If you really want to move tracks, you will need to use skipBackwards and skipForwards which are NOT exposed via the REST api, and are only in the websocket API.

29

@dvo A hack workaround for the REST API would be to first stop and then issue the prev command – that should skip songs backwards.

30

isn’t it stupid if you make half of the player in rest api and then putting the rest in the websocket?

31

You have to break some eggs to make an omelette… :wink:

– REST API is for external clients – low priority.
– Websocket is what Volumio’s UI uses – undocumented, no stable API, i.e the wild wild west :stuck_out_tongue:

32

rest api should be soooooo handy to use if you can use it in a normal way.
and wild wild west… i will call will smith for you :slight_smile: capt. james west or should i pick The Hateful Eight

33

Rest api propably never was meant to be the “go to” API choice for anything too serious, but its good way to let people build some hand gadgets from arduino or ESP mcu’s, from which the first one atleast would not be really an option with websocket only.

Nice catch, the indentation must have fooled my eyes before in there. i have had completely missed that, now i can make the “Swipe” actions work like i wanted within my app without any workarounds :stuck_out_tongue: (Little bit less spaghetti needed now)

I have most of it documented within the source codes, the odd behaviours i mean.
I can sure give my input about the API if someone wants to listen, but it will be quite harsh at times(i usually say what i think, without thinking how it comes out). But yeah i would have couple of major improvement ideas for it, which i believe would benefit everyone who uses it.

34

is there a way to make it usable for the noob? plugin ?

35

Easiest would be to just add skip{Back,For}wards to the REST API. Should be fine lines of copy paste…

36

if i know where to put it and what to paste i can do it.
that would fix my struggle with it. or add it in a newer release would even be better…
(that would give the full controle on the stream deck too.)

37

On looking into what skipBackwards really does, it doesn’t look like a general solution.

Guess spaghetti code is the way to go for now…

38

back button in browser is dead… doesn’t respond any more… not even seek 0 …

39

Sorry, I thought all was well.

I’ve re-packaged it and put the new zip file here;

I’ll try to wget it myself but have trouble miniuniping it still.