Music Client update...
> Hi Greg...
>
> Thanks for taking an interest...
>
> Greg Satz wrote:
>
>> First off I forgot the -c flag to mvpmc and the music client menu item
>> was still available. Selecting it caused mvpmc to (attempt to) core.
>> Once I got -c added, I have the following feedback:
>
> Yep, I looked and I see where I didn't bother to check in the
> main_select_callback/gui.c function. Good catch.
Right then, that's fixed.
>> 1) font size is small for the tv distance I am using. slimp3 lets you
>> change the font size but that results in giberish.
>
> I'll see what's available. The setup in the myth_main_attr/gui.c
> structure is the same as for the "About" pop up. But it's obvious that
> the font isn't the same (i.e. as readable). So far, I don't understand
> why this is. I would also like to use fixed fonts which are left
> justified (not centered).
Jon:
> This is changeable via the theme file, but the code in mclient_init()
> that sets the widget height is wrong, since it's based off the wrong
> themed attribute (about_attr instead of mclient_attr).
After implementing Jon's fix, the workings of these text widgets is
*much* less mysterious. I set mclient_attr.font to "FONT_LARGE" and now
it matches the rest of the OSD. I still need to do work here:
1) Why does about_attr.font = FONT_STANDARD result in big characters but
I have to mclient_attr.font = FONT_LARGE to get the same characters in
the mclient widget?
2) Why does the line wrap in the mclient widget even if there appears to
be enough room to not do it? Actually, how these lines of code work
will probably explain a lot:
(from mclient_init/gui.c)
===================
h = (mvpw_font_height(mclient_attr.font) +
(2 * 2)) * 8;
w = 500;
x = (si.cols - w) / 2;
y = (si.rows - h) / 2;
...
mclient = mvpw_create_dialog(NULL, x, y, w, h,
mclient_attr.bg,
mclient_attr.border,
mclient_attr.border_size);
===================
3) Occasionally I have noticed there are either extra line feeds or line
wrapping going on that don't make a lot of sense. For now I made the
widget taller so as not to cut off any text. Perhaps a fix font width
would clear some of these problems up.
>> 2) it looks like the text box that pops up when you select music
>> client prevents the screen saver from engaging. This may be an issue
>> with screen burn in. I need to correct myself. The screen saver pops
>> up behind the popup text box.
>
> Yes - I'll have to look into this. I am not sure if I just need to
> change some attributes of the mclient pop up -or- actually test for a
> screen saver flag and subsequently hide the mclient pop up.
>
Jon:
> I see this too. Historically, the screensaver was the last widget
> created, and thus it was "above" everything else. Since Rick is now
> creating his widget after the screensaver, this problem occurs. The
> fix is to raise the screensaver widget in screensaver_event().
That took a bit of hunting. I was looking for something like
"WndRaiseWindow". I eventually found "mvpw_raise(screensaver)". But it
doesn't appear to work as I expected. Here is a code snippet:
====================
screensaver_event(mvp_widget_t *widget, int activate)
{
static int visible = 0;
if (activate) {
visible = mvpw_visible(mvpmc_logo);
mvpw_unattached(mvpmc_logo, MVPW_DIR_DOWN);
mvpw_reparent(mvpmc_logo, screensaver);
mvpw_show(mvpmc_logo);
mvpw_show(screensaver);
mvpw_focus(screensaver);
mvpw_raise(screensaver);
screensaver_timer(widget);
} else {
====================
...I take that back, looks like it is working. Hum, I'll have to keep
an eye on this. Maybe a watched pot does eventually boil, but I think
it took a bit too long the first go around...
>> 3) How do I stop music from playing? The square button doesn't stop
>> the music.
>
>
> The pause button works. Seriously, I looked at the original code
> (mclient is an adaptation of Paul Warren's slimp3slave) and there was
> none there either. If you think about it, the STOP button is like
> pushing the PAUSE button then the "<<" button. I guess I could emulate
> the STOP button that way.
>
>> 4) Back takes me out of the music client and eventually stops the
>> music playing. My guess is the buffering from the slimp3 runs out then
>> it stops playing.
>
> I do have some clean up with respect to left overs in the mp3 play back
> buffer. But, this is more along the lines of a behavior that Jon is
> introducing for mvpmc in general. That is, the last media being played
> will continue as you search for new media. So, you should hear the
> mclient's music until you start playing something else. At least that's
> the way I think it is suppose to work.
Well, I looked in sf.net slimp3 CVS and found that the STOP code is not
there. Funny as STOP is clearly on the web page generated locally by
the server. I tried to implement the above "start over" & "pause"
sequence to emulate a STOP - but (I think) the two codes are de-bounced
by the server and the 2nd one never registers. I'll have to figure out
a way to delay the "pause" event later.
However, I did map the rest of the features that made sense. Here is a
list:
Keys sent to server:
MVPW_KEY_ZERO...NINE: 0...9
MVPW_KEY_DOWN: arrow_down
MVPW_KEY_LEFT: arrow_left
MVPW_KEY_RIGHT: arrow_right
MVPW_KEY_UP: arrow_up
MVPW_KEY_VOL_DOWN: voldown
MVPW_KEY_VOL_UP: volup
MVPW_KEY_REWIND: rewind to the beginning
MVPW_KEY_PAUSE: pause
MVPW_KEY_SKIP: forward to end
MVPW_KEY_FFWD: forward to end
MVPW_KEY_OK: play
MVPW_KEY_PLAY: play
MVPW_KEY_MENU: now_playing
MVPW_KEY_REPLAY: repeat modes
MVPW_KEY_RED: jump to search menu
MVPW_KEY_GREEN: add
MVPW_KEY_BLUE: shuffle modes
Special locally processed keys:
MVPW_KEY_YELLOW: debug = !debug; break; /* toggle debug mode */
MVPW_KEY_MUTE: mute mvpmc hardware
MVPW_KEY_STOP: "rewind to the beginning" & "pause" (doesn't work)
=================
>> 5) Shouldn't the skip and replay buttons advance and restart/back-skip
>> songs and the double-arrow buttons FF and REW?
>
>
> Ah, I thought you were talking about the ">>" and the "<<" buttons. Now
> I see. You were talking about ">|" and the "|<" buttons. Hum, I don't
> think there is a mapping for those. On the other hand, I can see where
> I might have these buttons backwards (i.e. ">>" instead of ">|").
> Anyhow, I don't see what I think you want - a skip forward / backward
> by, say, 10 seconds.
>
> The real problem here is that all the control is done by the server. So,
> any change in the play back flow is tricky. A fast reverse like on a
> normal CD player would be out of the question. I see a reverse server
> command that I haven't tried. And jumping forward may be nothing much
> more than flushing the hardware buffer. Something to try if nothing else.
I think it's going to be impossible to emulate a fast reverse function
and difficult to emulate a fast forward function.
Also note that I mapped the "|<" button to "replay mode" (not "back to
the beginning") because it is labeled "Replay". Let me know what you
think of this.
>> 6) Should mute work?
>>
>> I am able to control the mvp from slimp3's web interface just fine. If
>> there is anything else I should test, let me know.
>
> I don't have code for this. Probably because it's not something you
> tell the server. I see in video_callback/video.c there is a function
> call that may work for mclient called av_mute. I'll try that on the next
> go around.
That should work now.
>> After playing music with mclient and attempting to go to the replay
>> screen, I get the following crash:
>
>
> Yea, I think I have seen this. I probably didn't "gracefully" give up
> the hardware for the switch over from mplayer to replaytv. I'll have to
> experiment with some variation to figure out what I am missing.
I am going to have to do more work here later... running out of time...
...the above changes should be available on the web site:
http://home.xnet.com/~stuart/mvpmc/
....sf.net is acting up. The best I can do for now is a patch based on
a day old CVS set of code. I think Jon has alrady updated the mvplib
change in my latest patch...
|