[Freevo-users] Strange behaviour of music player on 1.x svn
Hi all,
after upgrading to 1.x svn, I am seeing a strange behaviour of the music
player component:
When the playlist reaches its end, the music stops and freevo goes back
to the directory view (where I started the player), but it doesn't react
on any keypresses.
When I hit ESC, the screen goes back to the last player view (i.e. last
title played, time stopped at the last position). When hitting up /
down, freevo returns to the correct directory view and reacts again as
expected.
I enabled debugging, here is the log:
-- snip --
2011-02-13 19:41:04,814 DEBUGdisplay.py (386): Setting current dialog to
CacheProgressDialog
2011-02-13 19:41:05,084 DEBUGdisplay.py (341): Closing dialog priority 1
2011-02-13 19:41:05,092 DEBUGrc.py (700): Focus App Context changed to
'menu'
2011-02-13 19:41:07,756 DEBUGaudioitem.py (192):
audio.audioitem.play(arg=None, menuw=)
2011-02-13 19:41:07,758 DEBUGplayer.py (51): PlayerGUI.__init__(item=With a
Little Help From My Friends (live): , menuw=, arg=None)
2011-02-13 19:41:07,763 DEBUGplayer.py (67): audio.player.play(player=None)
2011-02-13 19:41:07,765 DEBUGmplayer.py (88):
'file:///media/music_manuel/Joe Cocker/Hard Knocks Limited Premium Edition/16 -
With a Little Help From My Friends (live).mp3' good
2011-02-13 19:41:07,767 DEBUGmplayer.py (110):
audio.plugins.mplayer.play(item=With a Little Help From My Friends (live):
,
playerGUI=)
2011-02-13 19:41:07,782 DEBUGchildapp.py (298):
ChildApp2.__init__(app=['--prio=-20', '/usr/bin/mplayer', '-slave',
'-autosync', '100', '-nolirc', '-nojoystick', '-autoq', '100', '-screenw',
'1280', '-screenh', '720', '-fs', '-v', '-vo', 'null', '-ao', 'alsa', '', '',
'/media/music_manuel/Joe Cocker/Hard Knocks Limited Premium Edition/16 - With a
Little Help From My Friends (live).mp3'], debugname=None, doeslogging=0,
stop_osd=0)
2011-02-13 19:41:07,817 DEBUGchildapp.py (135): Running (list)
'/usr/bin/mplayer -slave -autosync 100 -nolirc -nojoystick -autoq 100 -screenw
1280 -screenh 720 -fs -v -vo null -ao alsa /media/music_manuel/Joe Cocker/Hard
Knocks Limited Premium Edition/16 - With a Little Help From My Friends
(live).mp3' with pid 2003 priority -20
2011-02-13 19:41:07,835 DEBUGchildapp.py (395): logging stdout child to
"/var/log/freevo/mplayer-stdout-1001-1297622467.log"
2011-02-13 19:41:07,852 DEBUGchildapp.py (395): logging stderr child to
"/var/log/freevo/mplayer-stderr-1001-1297622467.log"
2011-02-13 19:41:07,854 DEBUGchildapp.py (152): /usr/bin/renice -20 -p 2003
2011-02-13 19:41:07,867 DEBUGrc.py (106): rc.add_app: Setting app
(context audio)
2011-02-13 19:41:08,671 DEBUG__init__.py (158): Disabling livepause
buffering!
2011-02-13 19:41:08,673 DEBUG__init__.py (323): Buffering disabled.
2011-02-13 19:41:09,204 DEBUGmplayer.py (353): stream keyword found:
Artist: artist
2011-02-13 19:41:09,219 DEBUGmplayer.py (353): stream keyword found:
Genre: genre
2011-02-13 19:41:38,665 DEBUGthread pool member "None#1" exited
2011-02-13 19:52:06,857 DEBUGchildapp.py (414): stdout: no data, closing log
2011-02-13 19:52:06,861 DEBUGchildapp.py (414): stderr: no data, closing log
2011-02-13 19:52:06,920 DEBUGthread pool member "None#1" starting
2011-02-13 19:52:37,151 DEBUGthread pool member "None#1" exited
2011-02-13 19:55:24,513 DEBUGplayer.py (135): stop(restore_menu=True)
2011-02-13 19:55:24,515 DEBUGrc.py (111): rc.remove_app: Removing app
2011-02-13 19:55:24,516 DEBUGrc.py (689): Focused App= context='menu'
2011-02-13 19:55:24,521 DEBUGthread pool member "None#1" starting
2011-02-13 19:55:24,791 DEBUGrc.py (700): Focus App Context changed to
'menu'
2011-02-13 19:55:37,636 DEBUGrc.py (700): Focus App Context changed to
'menu'
2011-02-13 19:55:37,655 DEBUGdirectory.py (1089): overlay change
2011-02-13 19:55:38,198 DEBUGrc.py (700): Focus App Context changed to
'menu'
2011-02-13 19:55:38,200 DEBUGdirectory.py (1089): overlay change
2011-02-13 19:55:38,563 DEBUGrc.py (700): Focus App Context changed to
'menu'
2011-02-13 19:55:39,163 DEBUGrc.py (700): Focus App Context changed to
'menu'
2011-02-13 19:55:41,026 DEBUGdisplay.py (386): Setting current dialog to
ShutdownDialog
-- snip --
mplayer's stdout:
-- snip --
MPlayer SVN-r31918 (C) 2000-2010 MPlayer Team
CPU vendor name: GenuineIntel max cpuid level: 10
CPU: Intel(R) Atom(TM) CPU N270 @ 1.60GHz (Family: 6, Model: 28, Stepping: 2)
extended cpuid-level: 8
extended cache-info: 33587264
Detected cache-line size is 64 bytes
Testing OS support for SSE... yes.
Tests of OS support for SSE passed.
CPUflags: MMX: 1 MMX2: 1 3DNow: 0 3DNowExt: 0 SSE: 1 SSE2: 1 SSSE3: 1
Compiled with runtime CPU detection.
get_path('codecs.conf') -> '/home/freevo/.mplayer/codecs.conf'
Reading /home/freevo/.mplayer/codecs.conf: Can't open
'/home/freevo/.mplayer/codecs.conf': No such file or directory
Reading /etc/mplayer/codecs.conf: Can't ope
Re: [Freevo-users] Strange behaviour of music player on 1.x svn
On 2/13/2011 11:17, Manuel Borchers wrote: > Hi all, > > after upgrading to 1.x svn, I am seeing a strange behaviour of the music > player component: > > When the playlist reaches its end, the music stops and freevo goes back > to the directory view (where I started the player), but it doesn't react > on any keypresses. > When I hit ESC, the screen goes back to the last player view (i.e. last > title played, time stopped at the last position). When hitting up / > down, freevo returns to the correct directory view and reacts again as > expected. > [edit] > Anything I'm missing here or should I fill in a bug report? I can confirm this one too... it's one I first noticed when audio podcasts would finish and I thought I had screwed something up when I made the podcast item inherit from Audioitem instead of just Item.. It was later I'd discover this wasn't the case and that it also affected playlists when they ended 'naturally'. It's been around for quite a while in SVN, from what I remember, I just haven't remembered to bring it up here on the list yet. And I can't blame anyone for missing it... I figure a lot of audio playing activity doesn't let a playlist end on its own, either because it's a live stream (I do those a lot) or the user decides to end the playback before the playlist is done. For me, once the playlist ends the Freevo goes back to the directory/menu view (LCD follows too) but it won't respond to commands. Pressing ESC has no visible effect, but now the menu responds. It's like the player view is deleted/destroyed, but control is never returned to the underlying menu until the user presses ESC. I'm pretty sure this doesn't happen when the player has been detached, only when the player view is on screen. James __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Freevo-users mailing list Freevo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freevo-users
Re: [Freevo-users] Strange behaviour of music player on 1.x svn
On Sun, 13 Feb 2011, James Trietsch wrote: > On 2/13/2011 11:17, Manuel Borchers wrote: >> Hi all, >> >> after upgrading to 1.x svn, I am seeing a strange behaviour of the music >> player component: >> >> When the playlist reaches its end, the music stops and freevo goes back >> to the directory view (where I started the player), but it doesn't react >> on any keypresses. >> When I hit ESC, the screen goes back to the last player view (i.e. last >> title played, time stopped at the last position). When hitting up / >> down, freevo returns to the correct directory view and reacts again as >> expected. >> [edit] >> Anything I'm missing here or should I fill in a bug report? > I can confirm this one too... it's one I first noticed when audio > podcasts would finish and I thought I had screwed something up when I > made the podcast item inherit from Audioitem instead of just Item.. It > was later I'd discover this wasn't the case and that it also affected > playlists when they ended 'naturally'. > > It's been around for quite a while in SVN, from what I remember, I just > haven't remembered to bring it up here on the list yet. And I can't > blame anyone for missing it... I figure a lot of audio playing activity > doesn't let a playlist end on its own, either because it's a live stream > (I do those a lot) or the user decides to end the playback before the > playlist is done. > > For me, once the playlist ends the Freevo goes back to the > directory/menu view (LCD follows too) but it won't respond to commands. > Pressing ESC has no visible effect, but now the menu responds. It's like > the player view is deleted/destroyed, but control is never returned to > the underlying menu until the user presses ESC. > > I'm pretty sure this doesn't happen when the player has been detached, > only when the player view is on screen. This sounds like similar behaviour as the Image playlists are experiencing, ie they are both not working as expected. They will be on the hit list next after I've cleaned up a few things related to the change over to using kaa for everything now. Cheers Adam -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Freevo-users mailing list Freevo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freevo-users
