Fast-forward/rewind resign

[Triode]

>> I noticed that the scanner plugin didn't support multiple players - it
>> kept the current scan state in global variables rather than per
>> client.
>> I've just committed a fix for this to 7.1. R18754
>
> Thanks, but can you rework that so it stores the data needed using a
> method in $client? Using a global variable is bad and will lead to
> memory leaks.

Given its in a plugin it should probably use $client->pluginData to store
stuff.

[andyg]

On Apr 14, 2008, at 2:53 PM, Triode wrote:
>>> I noticed that the scanner plugin didn't support multiple players
>>> - it
>>> kept the current scan state in global variables rather than per
>>> client.
>>> I've just committed a fix for this to 7.1. R18754
>>
>> Thanks, but can you rework that so it stores the data needed using a
>> method in $client? Using a global variable is bad and will lead to
>> memory leaks.
>
> Given its in a plugin it should probably use $client->pluginData to
> store
> stuff.

Yeah good idea.

[max.spicer]

Originally Posted by andyg

On Apr 14, 2008, at 1:53 PM, max.spicer wrote:
>
> I noticed that the scanner plugin didn't support multiple players - it
> kept the current scan state in global variables rather than per
> client.
> I've just committed a fix for this to 7.1. R18754

Thanks, but can you rework that so it stores the data needed using a
method in $client? Using a global variable is bad and will lead to
memory leaks.

Interesting. The global is exactly what random mix does (or at least did...), so I'll take a look at that at the same time. Any good examples in existing code to copy?

Max

[andyg]

It's possible to do global variables like that but you have to be really careful and know when to clean up the data. It's much easier to keep all the data tied to the client object and then it goes away automatically. RandomPlay is probably full of memory leaks as well.

[max.spicer]

Originally Posted by andyg

It's possible to do global variables like that but you have to be really careful and know when to clean up the data. It's much easier to keep all the data tied to the client object and then it goes away automatically. RandomPlay is probably full of memory leaks as well.

A good example of code that puts custom data into the client object would be appreciated - it would save me a good bit of grepping. I'll hopefully have some time to look at this tomorrow.

Cheers,

Max

[max.spicer]

Originally Posted by Triode

>> I noticed that the scanner plugin didn't support multiple players - it
>> kept the current scan state in global variables rather than per
>> client.
>> I've just committed a fix for this to 7.1. R18754
>
> Thanks, but can you rework that so it stores the data needed using a
> method in $client? Using a global variable is bad and will lead to
> memory leaks.

Given its in a plugin it should probably use $client->pluginData to store
stuff.

Missed this reply somehow. Thanks - I'll check that out.

Max

[kdf]

>
> andyg;291487 Wrote:
>> It's possible to do global variables like that but you have to be really
>> careful and know when to clean up the data. It's much easier to keep
>> all the data tied to the client object and then it goes away
>> automatically. RandomPlay is probably full of memory leaks as well.
>
> A good example of code that puts custom data into the client object
> would be appreciated
check out the included scrobbler plugin. That's making extensive use of
pluginData.
-k

[max.spicer]

I notice that Client:luginData() replaces $client with Sync::masterOrSelf($client). Is this really right? I'd have thought there are many situations where you'd want to treat two clients differently, even if they do happen to be synced.

Max

[andyg]

On Apr 15, 2008, at 9:41 AM, max.spicer wrote:
>
> I notice that Client:luginData() replaces $client with
> Sync::masterOrSelf($client). Is this really right? I'd have thought
> there are many situations where you'd want to treat two clients
> differently, even if they do happen to be synced.

That's a good question, for all the plugins I'm using this for now it
seems to be the right thing to do. But I guess if for some reason you
wanted to seek on multiple synced players at the same time you might
have an issue with that.

[Millwood]

Certainly when players are synced and you do a seek on any one of them, it must effect them all, or they won't be sync'd anymore.

Have no idea if this is relevant to the code you're asking about.