Playing filtered selections in playlists

[GoogleCodeExporter]

What steps will reproduce the problem?
In the current version of TunesRemote SE if you filter or search in a playlist 
and then play a track, it will start at the selected track but play through the 
whole list unfiltered.

What is the expected output? What do you see instead?
Much like filtering in the main library I would expect to only play through the 
filtered list.

Original issue reported on code.google.com by nick.gl...@lycos.com on 8 Jun 2011 at 9:22

[GoogleCodeExporter]

I am very new to both TunesRemote and MediaMonkey/MonkeyTunes, so I am slowly 
feeling my way through the nontrivial issues of getting these (including local 
FireWall and Router port-forwarding, etc.) all working together.

That said, I am certainly experiencing this disconnect between what I am 
getting and what I would intuitively expect as coordinated behavior between 
TunesRemote and the MM/MT server. I will attempt to refine my observed behavior 
description and add to the evolving thread here. But, so far in a nutshell, I 
seem to be getting this "server thinks 'next' is next in its master collection 
playlist' rather than next being the selected song in TunesRemote. Nor do I 
have any volume/muting control, etc. from what I had hoped (and expect is the 
design of) TunesRemote as a 'remote control' app.

Since both critical 'ends' (TunesRemote and MediaMonkey) and the 'middle-man' 
(MonkeyTunes) are all their own 'moving targets' (along with the desire of each 
to be multi-other compatible) I realize that things go akimbo now and then. I 
expect that this is the case now and that if things stay stable enough among 
the piece-parts for a while, that a tweak here and there will have this all 
working as expected.

Keep up the GREAT work and I look forward to this combo of remarkable products 
providing the 'holy grail' of 'mix and match' music access my wife and I would 
like to have for our listening pleasure.

Original comment by sohod...@gmail.com on 12 Jan 2012 at 5:33

[GoogleCodeExporter]

I think your Next issue might be similar to what this user is reporting...

http://code.google.com/p/tunesremote-se/issues/detail?id=33

Have you tested MonkeyTunes on TunesREmote+ for Android and Apple Remote on 
iPhone?  You will see they both work quite well I think it is just a matter of 
hammering a few kinks out of this TunesRemoteSE project.

Original comment by mellowaredev on 12 Jan 2012 at 11:34

[GoogleCodeExporter]

Hi 'Melloware',

I am an Android- and Apple-less happy user... currently focused on MM/MT on 
server PC and TunesRemoteSE on client PC (both Win7 x64).

Having been a software designer/developer for decades, I have done some 
simplifying testing/user-case investigation and will provide a report later 
today that should clarify more precisely what is going on with this 
configuration. In a nutshell, yes, I believe this will be a relatively simple 
matter of hammering out a communication 'gotcha' between TRse and MM/MT.

More soon,
--Jim--

Original comment by sohod...@gmail.com on 12 Jan 2012 at 4:42

[GoogleCodeExporter]

I think the problem in both issues is related to what TunesRemote-SE does when 
it updates the now playing song.

In Mediaplayer.java updatePlayingSong TunesRemote looks up the pointer to the 
new song by attempting to look it up in the playlist/database it has previously 
loaded.  This is useful as it is then easier to check the now playing song by 
doing a simple comparison.

Melloware could you please check that MonkeyTunes is providing consistent 
database_id, playlist_id, song_containter_id, and song_id in the canp now 
playing field in the status update.

Thanks

Nick

Original comment by nick.gl...@lycos.com on 12 Jan 2012 at 4:53

[GoogleCodeExporter]

That might be the problem I always return the same LIBARY_ID in the CANP 
because MediaMonkey Now Playing does not quite have the same concepts as iTunes 
so I return the static constant value in the CANP for LibaryID as below...

private const int PLAYLIST_LIBRARY_ID = 99999999;

Original comment by mellowaredev on 12 Jan 2012 at 5:28

[GoogleCodeExporter]

To clarify my above statement it means that MM does not have this concept 
everything is in the Now Playing list it doesn't know whther it was loaded by a 
playlist, or simply a user adding it manually or whatever.   iTunes does keep 
this concept and thus it can set the PlaylistID of where the next track is 
coming from.   Since MM doesn't I always just return the LibraryID since I know 
it is always coming from Now Playing.

Original comment by mellowaredev on 12 Jan 2012 at 7:31

[GoogleCodeExporter]

Nick and MelloMan,

I am sure you two are on the right track and likely have nailed this issue at 
some level that will let you fix this (and any related) issue to whatever 
extent possible. But just to confirm your conversation and contribute my "fresh 
eyes" perspective, I'll describe a simple use case that clearly reflects the 
issue of "WYGAOTWYE" (what you get as opposed to what you expect -- I think 
it's a Native American Indian term).

--MM/MT Server Side--

1. I created an empty Playlist called "Default Empty."

2. In MM's "Options/Player/Auto-DJ/Now Playing" panel I enable Auto-DJ, set it 
to maintain 'None' upcoming files in Now Playing... Add file from "Playlist" 
and 'Choose' Default Empty. I also set Now Playing to retain 0 previous files 
in its list.

3. Restart MM/MT and it is in pristine shape. Nothing in Now Playing. I don't 
do anything from this point in interaction with MM/MT.

--TRse Client Side--

1. I launch TRse and select my MM/MT server's published/paired library. TRse 
does its loading thing on my 8,857-song library.

2. Everything looks cool. The Genre/Artist/Album listpanes are filled 
appropriately. The individual library tunes are all listed in the panel below. 
The left panel shows Library, Genius, and Playlists. No album art is in the 
lower left now playing panel and the player controls and timer-slider widget 
are stopped/emptied. So far so good.

3. I now drill down into one of my albums by clicking on an album name in the 
upper-right Album listpane. The Song pane refreshes with just the songs in that 
album.

4. All is still good, as expected, both client and server side. I double-click 
on any of the tunes listed in this album... and things go akimbo.

--MM/MT Server Side--

1. The Now Playing Queue list now refreshes (slowly as it's a listpane filling 
with 8,857 tune items) by placing ALL the library tunes in the list. And that's 
it at the moment. No tune starts playing. Only the Now Playing Queue has been 
changed.

--TRse Client Side--

1. I am doing a 'Huh? What gives? As there is no visible way to know what has 
gone on server-side. All that I know is that the song I tried to start playing 
is not playing...

2. Now I try the next "logical step" and click the Play button while the tune I 
tried to double-click play is still selected.

3. This starts the first song of the first album of the library playing, not 
the tune I thought I was going to play. The Now Playing album art appears along 
with the album title, song title, and artist... for the actual playing song, 
not the one I requested.

4. Subsequent clicks on the Next Song player button will walk through the 
(unseen) Now Playing queue.

5. A double-click on any title in the Song panel will fully refresh the 
server's Now Playing queue with the full contents of the Library and a Next 
click will play the first song of the first album in the newly refreshed full 
library list.

[[Observation/Wish-list: The lack of a TRse pane to show the MM/MT Now Playing 
queue contents is a nontrivial missing feature. Sure, an interactively 
manipulable listpane would be GREAT. But short of that, just being able to SEE 
the contents of the Now Playing queue would be very helpful. You could see that 
the tune you are requesting is queued and will play when it gets its turn.]]

I hope this information is helpful in confirming your understanding of what's 
acting up between TRse and MM/MT. When these are all working as expected it 
will be AWESOME! :-)

--End Use Case--

Original comment by sohod...@gmail.com on 13 Jan 2012 at 2:19

[GoogleCodeExporter]

Great detail on your post!!!

In my opinion this is not an ideal scenario.  What TSRE must be doing is 
calling the "Play Playlist" functionality with the entire library id.  THis 
loads all 8800 tracks into the Now Playing Window.  I have 96,000 tracks in my 
MM and this takes almost 5 full minutes to complete.

When being controlled from the TR+ Android client or iOS Apple REmote never is 
the entire library loaded into the Now Playing and the "MonkeyTunes DJ" 
playlist represents what is in the Now Playing window and on the Apple Remote 
you can add individual songs to the Now Playing by editing that MonkeyTunes DJ 
playlist.   The client side apps also when you click a song in an album it 
loads that single album into the Now Playing and starts playing the song you 
have selected.

Original comment by mellowaredev on 13 Jan 2012 at 3:24

[GoogleCodeExporter]

Hi Mello,

Yes, your above description sounds very much like what I would expect to be the 
behavior of TRse as a remote client of MM/MT.

I was a hard-core Smalltalk designer/developer for over 20 years before leaving 
the Corporate Road Warrior life -- one reason being that I loathed the 
necessity of leaving "Smalltalk Nirvana" when Java ascended from the ooze of so 
many enterprise-scale C++ mega-projects that where crashing and burning. (But 
that's another story...) At any rate, I am no Java expert, but I do know enough 
to be potentially helpful. So I have checked out source and will start to at 
least get a conversational understanding/appreciation of what is going on with 
TRse and its interface with MM/MT.

When TRse has the basic functionality that you so cogently described above, 
this will be an awesome combination of excellent products! :-)

Original comment by sohod...@gmail.com on 13 Jan 2012 at 4:22

[GoogleCodeExporter]

Excellent!  Much appreciated for the help.

I will also see if I can dedicate some time to debugging this as I think this 
project is a very useful selling point for MonkeyTunes.  Because most of my 
users have an iOS device or Android but a lot of people also ask if they can 
control it from another PC in the house.

Original comment by mellowaredev on 13 Jan 2012 at 11:25

[GoogleCodeExporter]

Mello,

Spot on with this..."but a lot of people also ask if they can control it from 
another PC in the house."

I know I can't come up to speed to contribute any code ASAP, but I can do 
something equally useful.

As incentive/reward for your effort, I will commit to creating a Camtasia-based 
screencast to showcase the installation, pairing, and essential features of 
this obviously killer combo. I'll publish it to YouTube and you can link to it 
where/whenever is needed.

And this is not just and "in the house" thing. I believe that having "community 
control" over in-office tunes will be a big plus for folks who will use 
TRse/MM/MT in small business and departmental office environments. 

I know this is true, at least, for my wife and me in our home office. I wrote a 
REBOL-based mini-app that runs on her box and listens on our network to a 
OpenPandora app on my box (I tweaked to add a "what's playing" 
network-broadcast API). This was an 'info-only' feature -- album art with 
linked text of album, artist, tune which opens her browser for full info. Being 
able to contribute/control the queue is obviously even better. But for many 
situations, just being able to see/explore "Now Playing" is a useful feature 
and would reduce "office chatter/distraction." Tap this small-biz/dept market 
and I believe you will have a nontrivial new stream of well-deserved MT income.

Original comment by sohod...@gmail.com on 13 Jan 2012 at 2:50

[GoogleCodeExporter]

I will start a thread over on the MT forums so we don't have to keep it in the 
context of this defect.

Thread here:

http://forum.melloware.com/viewtopic.php?f=16&t=9642

Original comment by mellowaredev on 13 Jan 2012 at 11:15