PDA

View Full Version : CLI: 6.5 - issuing "pause 1" doesn't trigger status message



gerry_duprey
2006-03-09, 13:45
Howdy,

So I'm pretty far along with the CLI classes now -- almost everything is working. I just ran into an interesting case though.

I subscribe to a player status messages with "status subscribe:0" and test that if I change virtually anything on the player via the web interface, I get a report/notice.

However, if I issue a "pause 1" for the player from the same CLI connection I'm listening for status messages on, I never get a report confirming the player paused. I can confirm on the slimserver web page the player is paused, but I don't get a report. I can also confirm that other CLI connections do get the report.

I've noticed the same behavior with "mixer muting 1" -- the player mutes, but no report. Make the same change from the slimserver web page and I get a report.

I've confirmed it's not just the presence of a 1 or 0 after the pause/muting command -- using them in their more traditional toggle mode (i.e. no parameter) results in the same thing -- the command takes effect, but there is no report sent to the initing client.

I could just setup two connections -- one for issuing commands and one for listening for status reports, but I don't get the impression that should be needed.

I'm using the 6.5 slimserver build 3/8/2006

Gerry

gerry_duprey
2006-03-09, 15:03
Actually, I'm finding this with more commands. Issuing a "play", "stop" or "pause" to a player that you are subscribed to doesn't send a status report/notice to the CLI the sent the command. The web interface and the other CLI clients do get a status report when this happens.

Gerry

Fred
2006-03-10, 11:04
True, but only I think if listen or subscribe is enabled on the same connection!

In any case, fixed. Fixed the other one too. SVN 6546, next nightly!

Thanks

Fred

gerry_duprey
2006-03-11, 10:01
Howdy,

Did you check that in for last nights build? I just downloaded/installed the nightly and installed and things seem to have changed.

Now if I issue a "status subscribe:0" for a player, I no longer get *any* updates -- regardless of whether the changes to the player came from the current CLI connection or from someone else. Similary, if I issue a "status subscribe:15", I still get no reports when there is a change AND I don't even get a status message every 15 seconds.

With the previous (3/8) build, if I was subscribed on a CLI connection and issues a "pause", the player would pause, but I would not received a status message. However, if I paused the same player directly or using the web interface, I did received a status message. In otherwords, changes to the player as a result of commands on the CLI connection I was subscribed on produced no report, but any other sort of change did.

Now, other than when I issue a "status" command, subscriptions don't seem to be sending anything.

My entire CLI dialog is:

<initial connection>
listen 1
<slimserver echos listen 1>
b1:d1:88:1e:79:12 staus subscribe:0
<slimserver sends current status for player>
b1:d1:88:1e:79:12 pause 1
<slimserver echos the "pause 1" -- no status report though>

After that, any changes to the player from anywhere fail to generate any status notices/reports.

Any thoughts of things I should check (there are no odd entries in the slimserver log).

Gerry

gerry_duprey
2006-03-11, 11:27
Actually -- forget the entire last post.

In fact, things do in fact seem to be working correctly with the 3/11 distro -- commands issued from a subscribed CLI connection are getting status reports now!

Thanks!

Gerry

gerry_duprey
2006-03-11, 11:40
Howdy,

Is there anyway to turn off the return title: attribute when a player is reporting it's list of queued songs (status) or when fetching the tracks of a playlist (playlisttracks)?

All I really need is the ID (I've already downloaded all tracks so I can match a track ID locally). I'm already passing tags: (i.e. no tags) to the playlistracks command and that cuts things down to the title and ID for each track. I'm just looking to cut the title out so I can request more tracks in a single request (since each request has a slight delay in responding).

If not, any thoughts on what it would take to add a "bulk-download" tag to playlisttracks and status that would

1) disable title
2) Return the tracks IDs in the correct order (eliminating the need for the playlist index: tag

It would allow very quick bulk downloads for both cases.

No biggie if not -- just looking to speed up my transactions with the SlimServer some.

Gerry

Fred
2006-03-11, 17:02
Removing title and/or playlist index will not really make the CLI faster. What's your constraint, response size?

Adding a tag for title is easy, except it would break existing clients using "tag:" and expecting a title.

Fred

gerry_duprey
2006-03-11, 17:21
Howdy,

It's not a huge issue -- I'm just trying to cut out 1) passing unneeded data from the transaction and 2) cut out unneeded resources in parsing the unneeded data.

The majority of my time is spent waiting for the slim server to respond to queries. I'd like to up the "count" parameter for these requests to minimize the number of them I make (assuming each one starts a new query on the DB) and if I could shrink the space each track took up, I could increase the count size and get more tracks per call.

As I said, it's not a biggie and probably wouldn't be a huge speed up. I could imagine a tag that was basically an anti-tag (i.e. if tag X is present, then titles are suppressed), but that I think that would be a new precident and maybe not the best solution.

Gerry

Fred
2006-03-13, 13:57
if I could shrink the space each track took up, I could increase the count size and get more tracks per call.

My question is what's your constraint here? Why can't you simply "up the count"? The travel time is not going to be noticeably bigger, so I can only assume you have some bandwidth or buffer contraint of sort?


As I said, it's not a biggie and probably wouldn't be a huge speed up. I could imagine a tag that was basically an anti-tag (i.e. if tag X is present, then titles are suppressed), but that I think that would be a new precident and maybe not the best solution.

As yourself have experienced, the whole thing starts to become quite complicated already so "antitags" sounds confusing. However we can imagine a "id_dump" parameter or something...

Feel free to add an enhancement request if you think this is worth it. I am mitigated, as the command won't run faster...

Fred

gerry_duprey
2006-03-13, 14:01
I actually have done just that -- upped the counts -- and it really didn't add anything to transit time (though did reduce my overall query time, as you'd expect). I'm working on a local LAN, so I'm pretty OK bandwidth-wise -- it was just my sense of "waste" (i.e. bandwidth on stuff I don't need) that was prompting this, but I agree that it' s no biggie and fine as things are.

Thanks!

Gerry