Problem with MPD client but probably POE user error

[John]

Hello,

I am working with POE::Component::Client::MPD for the first time and
attempting to get the example provided working. I have modified it
along the way but results have been the same (code is below).

The MPD (Music Player Daemon) logging shows the client connect and
disconnect (when I control-c). However, none of the events I send get
to the daemon (also running on localhost with default port). I added
print statements at pretty much all the entry points for events within
MPD.pm and none of them get hit. Therefore maybe this is not a problem
with MPD.pm but my usage of POE.

Also note that I can use the command line client that comes with MPD to
interact with the daemon and that works as expected as well as it
generates logging information.

Which direction should I go in to track it down?

Thanks,

John

#!/usr/bin/env/perl

#


use warnings;
use strict;

use FindBin qw{ $Bin };
use lib "$Bin/../lib";

use POE;
use POE::Component::Client::MPD;

POE::Component::Client::MPD->spawn( {
alias => 'mpd',
} );

POE::Session->create(
inline_states => {
_start => \&start,
_stop => sub { print "bye-bye\n"; },
mpd_result => \&result,
mpd_error => \&error,
status_msgs_to => \&clutter,
}
);
POE::Kernel->run;
exit;


sub start {
my $k = $_[KERNEL];
$k->alias_set('client'); # increment refcount

print "hello there\n";
$k->post( 'mpd' => 'current' );
$k->post( 'mpd', 'coll:all_files' );
print "done with start\n";

}

sub result {
print "yeah!\n";
}

sub error {
print "got an error\n";
}

sub clutter {
print "got some clutter!\n";

}

[Rocco Caputo]

Hi, John.

I don't see anything obviously wrong in the code you provided. I don't have MPD, and I'm not familiar with the module you're using, but I can offer some general POE advice.

POE has some debugging switches, documented in POE::Kernel. I recommend at least enabling: ASSERT_EVENTS, ASSERT_USAGE, and ASSERT_RETVALS. You can do this in your shell:

export POE_ASSERT_EVENTS=1
export POE_ASSERT_USAGE=1
export POE_ASSERT_RETVALS=1

Or to turn them all on (and a bit more) in one fell swoop:

export POE_ASSERT_DEFAULT=1

Then run your program. Hopefully POE will warn you about something relevant.

--
Rocco Caputo <rca...@pobox.com>

On Feb 4, 2014, at 07:56, John <jo...@tonebridge.com> wrote:
>
> none of the events I send get
> to the daemon (also running on localhost with default port).

> maybe this is not a problem
> with MPD.pm but my usage of POE.
>

[John]

Thanks!

I updated modules to latest and changed the program since I sent the
original email. Below is output with ASSERT set.

No problem if nothing leaps out as I am still working it.


With POE_ASSERT_DEFAULT=1:

hello there
bye-bye
=== 2437 === Please address any warnings or errors above this message,
=== 2437 === and try again. If there are no previous messages, or they
=== 2437 === are from within POE, then please mail them along with the
=== 2437 === following information to bug...@rt.cpan.org:
---
<dt> Cannot resolve ``mpd'' into a session reference
-----
at ./client.pl line 36.
main::start(undef, POE::Session=ARRAY(0x2b3b188),
POE::Kernel=ARRAY(0x15801a0), HASH(0x11e4590), "
_start", POE::Kernel=ARRAY(0x15801a0), undef,
"/usr/lib64/perl5/site_perl/5.12.4/POE/Kernel.pm", 1479, ...
) called at /usr/lib64/perl5/site_perl/5.12.4/POE/Session.pm line 464
POE::Session::_invoke_state(POE::Session=ARRAY(0x2b3b188),
POE::Kernel=ARRAY(0x15801a0), "_start",
ARRAY(0x167b968), "/usr/lib64/perl5/site_perl/5.12.4/POE/Kernel.pm",
1479, undef) called at /usr/lib64/pe
rl5/site_perl/5.12.4/POE/Kernel.pm line 1067
eval {...} called at
/usr/lib64/perl5/site_perl/5.12.4/POE/Kernel.pm line 1066
POE::Kernel::_dispatch_event(POE::Kernel=ARRAY(0x15801a0),
POE::Session=ARRAY(0x2b3b188), POE::Ses
sion=ARRAY(0x2b3b188), "_start", 4, ARRAY(0x167b968),
"/usr/lib64/perl5/site_perl/5.12.4/POE/Kernel.pm", 1
479, undef, ...) called at
/usr/lib64/perl5/site_perl/5.12.4/POE/Kernel.pm line 1476
POE::Kernel::session_alloc(POE::Kernel=ARRAY(0x15801a0),
POE::Session=ARRAY(0x2b3b188)) called at
/usr/lib64/perl5/site_perl/5.12.4/POE/Session.pm line 192
POE::Session::try_alloc(POE::Session=ARRAY(0x2b3b188)) called
at /usr/lib64/perl5/site_perl/5.12.4
/POE/Session.pm line 373
POE::Session::create("POE::Session", "inline_states",
HASH(0x11bffd8)) called at ./client.pl line
24

[John]

On 02/05/14 10:36, Nick Perez wrote:
> It has probably failed to connect to mpd. I would make sure you define
> status_msg_to and see that you are actually getting this connected
> event. Also make sure mpd is actually listening where you think it is.
> For example it could be listening on IPv6 localhost.

Thanks...in the code I provided in the original email I think I
addressed these points. Summarizing, when running mpd in the foreground
with verbose logging on I can see the the connect from the client and
the disconnect when I control-c out of the client. The event
"status_msg_to is defined and nothing is sent it.

In the assert output here is the error: <dt> Cannot resolve ``mpd'' into
a session reference.

Digging through the Kernel.pm code, it seems POE is trying to resolve
'mpd' to a session reference through various methods but it cannot. So
I added Dumper output before the attempt to do the post to 'mpd'. Based
on my review it does seem like session exists and has correct alias:


$VAR1 = bless( [
{
'1' => [
bless( [
{
'alias' => 'mpd'
},
{
'default' => 1
},
{
'_parent' => [
bless( {

'session_id' => 1,
'heap'
=> $VAR1->[0]{'1'}[0][0]
},
'POE::Component::Client::MPD' ),
'PARENT'
],
'mpd_error' => [

$VAR1->[0]{'1'}[0][2]{'_parent'}[0],
'mpd_error'
],
'mpd_disconnected' => [

$VAR1->[0]{'1'}[0][2]{'_parent'}[0],

'mpd_disconnected'
],

[snip]

So, based on what I see this doesn't make much sense. Next step for me
based on my level of knowledge is to start hacking these to gain some
insight. If anyone has better direction please let me know.

John

[John]

> So, based on what I see this doesn't make much sense. Next step for me
> based on my level of knowledge is to start hacking these to gain some
> insight. If anyone has better direction please let me know.

I added some print statements in POE's Aliases.pm in the sub
_data_alias_resolve to see what aliases POE thought existed at any point
in time. It turns out that at the time _start is executed the mpd alias
was not registered yet! I figure it is timing and not location.

Anyway, for debugging purposes I added a delayed event and that worked!

I will work with it to get a better understanding if it is timing or
just having it in _start but it seems I should be good not rushing things.

John

[Rocco Caputo]

On Feb 5, 2014, at 16:27, John <jo...@tonebridge.com> wrote:

> I added some print statements in POE's Aliases.pm in the sub
> _data_alias_resolve to see what aliases POE thought existed at any point
> in time. It turns out that at the time _start is executed the mpd alias
> was not registered yet! I figure it is timing and not location.
>
> Anyway, for debugging purposes I added a delayed event and that worked!
>
> I will work with it to get a better understanding if it is timing or
> just having it in _start but it seems I should be good not rushing things.

I didn't notice this problem because I expected POE::Component::MPD to set its own alias in its own _start routine.

_start is called before POE::Session->create() returns. The predictable timing can be used to avoid problems like this.

--
Rocco Caputo <rca...@pobox.com>