[Koying]

IMO, one of the last bit of notification missing to avoid a client having to poll xbmc is some kind of playing progress notification.

I think this specific one should be off by default.
It should have some intelligence, to cope both with short clips and long movies.

What do you think?

[Mizaki]

What I do currently is when something begins to play, I then start polling for the time (and a few other things that may be on notification now but I haven't checked). If you leave it up to the remote to start polling at least they can decide how often they want to poll. I'm thinking a notification would just have to spam every second or so. Unless you had a better idea in mind?

Thanks for the playlist notification as well.

[Koying]

Well, first, it would be off by default, so a client would only use it if it wants to.

Second, it should be smart, notifying differently depending on the length of the media.

Fact is that now, a client HAS to implement a polling loop if it wants to display a progress bar, and it is probably the only compelling reason to do so remaining.

[Montellese]

Unfortunately it's currently not possible to disable notifications on a per-notification level so you can either disable all notifications of a namespace (in this case Player) or none of them. Furthermore notifications aren't only JSON-RPC specific, they are also used within XBMC e.g. in the new UPnP to trigger certain behaviours/actions so spamming something there is not very nice. In general I don't like constantly spamming something if there's a better solution.

Back when I wrote the iMON LCD client I did the following: I listened to the Player events which basically told me when something is playing etc and kept a local state of the player. Then I retrieved all the information about the playing item (metadata + runtime etc) through JSON-RPC once and started a timer which I then used for showing a progress bar. Obviously the timer may not be perfectly synchronized with XBMC so you'll get some drift but that will only be noticeable after a while (probably several hours which is not really a use case for songs, episodes or movies). So depending on how precise you want to be you do your polling e.g. every 10 or 30 seconds or whatever. If you get a Player.OnPause, you pause your timer etc. That way you will save a lot of requests and it's also less work for XBMC itself. Furthermore this allows the client to do his update routine in whatever interval he likes and the client isn't bound to a "smart" interval specified by XBMC so clients are much more flexible. IMO that's the way it should work.

[Koying]

Re notification level, you could imagine a specific level for this.

But whatever. If everybody thinks polling is fine, i don't mind that much

[Millencolin007]

Unfortunately it's currently not possible to disable notifications on a per-notification level so you can either disable all notifications of a namespace (in this case Player) or none of them. Furthermore notifications aren't only JSON-RPC specific, they are also used within XBMC e.g. in the new UPnP to trigger certain behaviours/actions so spamming something there is not very nice. In general I don't like constantly spamming something if there's a better solution.

Back when I wrote the iMON LCD client I did the following: I listened to the Player events which basically told me when something is playing etc and kept a local state of the player. Then I retrieved all the information about the playing item (metadata + runtime etc) through JSON-RPC once and started a timer which I then used for showing a progress bar. Obviously the timer may not be perfectly synchronized with XBMC so you'll get some drift but that will only be noticeable after a while (probably several hours which is not really a use case for songs, episodes or movies). So depending on how precise you want to be you do your polling e.g. every 10 or 30 seconds or whatever. If you get a Player.OnPause, you pause your timer etc. That way you will save a lot of requests and it's also less work for XBMC itself. Furthermore this allows the client to do his update routine in whatever interval he likes and the client isn't bound to a "smart" interval specified by XBMC so clients are much more flexible. IMO that's the way it should work.

I have implemented the same thing in Music Pump XBMC Remote and it works relatively well. Only problem is that on some nightly builds some notifications are not sent or are sent twice.

[Montellese]

Yeah older nightly builds (right after the AE merge) don't have all the notifications because they got lost in the re-write of XBMC's audio player. But in recent nightly builds all notifications should be sent out again. The OnPlay notification is still sent twice when listening to music but I wasn't able to fix that yet (nor was DDDamian) but twice is better than never