-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add GUI + PAUSED to track status #2674
Conversation
Voight Kampff Integration Test Succeeded (Results) |
Voight Kampff Integration Test Succeeded (Results) |
Is there any chance we're going to want to add other queuing services in the future? It raises the question for me if we anticipate any other services if we should abstract this rather than adding and shifting the ints each time? I can't actually think of any others right now though, so perhaps I'm over thinking it. Alternatively should we use two digit status ints for all eg:
Especially if we're going to want the service options added to each of the major status codes, we could reserve the x0, x1, x2 codes (or more) for specific services to provide consistency eg
|
Is the order here of any importance? It mainly use the IntEnum to be able to serialize the to json without manual conversion. I guess for manually parsing the messages it's easier to see if they're grouped (anything starting with 3 is a queue message, etc) |
Yeah, you can also use comparison operators with IntEnum's right? So could do things like:
and would mean if we did want to add a new status code in between existing codes, then we don't have to shift all the other codes around. It may even be beneficial to re-use the majority of the codes for similar status tracking in future systems like a file copy, a robot arm, 3d printer, ... Eg
|
the whole point of an Enum is that you will never compare with ints directly
should be
there are no assurances that the int will remain constant i do like the double digits idea so we can do comparisons like above however i do not think the printing example really fits here because this is about playback, and the enums should not really need to be expanded again ideally, i do see a few major categories
maybe add a few more status for the enclosure only? these 4 categories should account for everything |
also note that paused etc do not need to differentiate between gui/audio/enclosure, those are "global" status, and are only reverted with a new PLAY status these are supposed to be further integrated into the audioservice, the playlist handling in particular, but thats a bigger discussion to be had in a follow up PR. Specifically i want to discuss if these status messages should re-order/add to the playlist in audio service or be "read only". Either way the queued and playing will be important to tell apart in the audio service, the pause etc no so much |
Yeah the other service status's was a bit left field, just thinking at the fringes and it will be good if we have other services like this in the future for them to be consistent. But we really don't need to try and pre-empt all that right now. So how does the following look: class CPSTrackStatus(IntEnum):
DISAMBIGUATION = 10 # not queued for playback, show in GUI
PLAYING = 20 # CPS is handling playback internally
PLAYING_AUDIOSERVICE = 21 # Skill forwarded playback to audio service
PLAYING_SKILL = 22 # Skill forwarded playback to another Skill
PLAYING_GUI = 23 # Skill forwarded playback to GUI
PLAYING_ENCLOSURE = 24 # Skill forwarded playback to enclosure
QUEUED = 30 # Waiting for playback to be handled inside Skill
QUEUED_AUDIOSERVICE = 31 # Waiting for playback in audio service
QUEUED_SKILL = 32 # Waiting for playback in another Skill
QUEUED_GUI = 33 # Waiting for playback in GUI
QUEUED_ENCLOSURE = 34 # Waiting for playback in enclosure
PAUSED = 40 # media paused but ready to resume
STALLED = 60 # stalled state helps to know when to show the buffering ui
BUFFERING = 61 # In case it's an online source the buffering state or
END_OF_MEDIA = 90 # helps to know if we want to do autoplay or something
|
skill handling means that audioservice can not control playback, for example spotify plays with raspotify, this means that the skill itself needs to handle next/prev/pause and so on list above looks good, will make those changes Buffering means its loading the data, stalled means its not loading, this was a suggesting by @AIIX so maybe he can explain the rationale better |
That makes sense, maybe we can tweak the descriptions:
|
Voight Kampff Integration Test Succeeded (Results) |
2 similar comments
Voight Kampff Integration Test Succeeded (Results) |
Voight Kampff Integration Test Succeeded (Results) |
Gotcha, makes sense if they have some common actions and some specific actions to group them in a range. |
Voight Kampff Integration Test Succeeded (Results) |
d20aea5
to
a8e9af8
Compare
Voight Kampff Integration Test Succeeded (Results) |
When working on #2660 i realized we also need status to know if playing is using the gui, specially for video/games. This adds 2 more status to the Enum
also see MycroftAI/skill-playback-control#35