From: Ken M. <zar...@nt...> - 2013-04-12 00:22:45
Attachments:
xine-ui-crazy.patch
|
OK people, trying to subscribe to your -bugs doesn't work (it doesn't mail the authentication, and it looks as if the list might be defunct), and posting on -users got no response, so now I'm here on -devel with a crazy patch to work around a regression. I've been using xine-ui-0.99.7 for some time, but not very much. Looking back, it seems I must have been on the commandline when I tested it. Eventually I discovered that trying to open a file with the right mouse button and Open -> File wasn't working. This is on x86_64 linuxfromscratch, and I first noticed at the end of my current desktop build - LFS-7.3 (still gcc-4.7 series), everything else generally current released versions. As I noted on -users, on LFS we have current autotools. To run autogen.sh I need to do sed -i 's/AM_CONFIG_HEADER/AC_CONFIG_HEADERS/g' configure.ac I also had a couple of other old seds which I'm happy to say are no longer needed in current hg : my comment on -users saying we did still need one was wrong, but it appears to do no harm [ I've just retested 0.99.7 without my patch below and without the seds, it is definitely broken ]. And I did need them for 0.99.6 when I was bisecting. At first I thought this might be down to using libpng-1.6, but when I checked an older LFS-7.2 build from a few months ago I realised that it too wasn't working. There is a blog post about this, http://slackblogs.blogspot.co.uk/2012/09/xine-ui-reverted.html but I couldn't find anything else relevant. I guess most people either pass the filename on the command line, use the MRL browser, or use a desktop environment ? Or does anyone have a version of xine-ui-0.99.7 or current hg where you can open a file with right-click, Open, File and it works ? If so, what architecture and distro or system are you using ? Before I posted on -users I cloned the hg repository and bisected. That told me that r3004 (allow jpeg for splash and logo, move the splash and logo down a source dir) was the first bad commit. That seemed impossible. Since then I've spent a lot of time instrumenting 0.99.7 and 0.99.6 to find out what changed. In the end, I discovered that, apparently for all versions since r3004 (but only fully tested in 0.99.7 and r3134 which is the current version) the status of the stream has somehow changed. This, I believe, is impossible - as far as xine-ui is concerned, it's an opaque and incomplete data type. But all my testing has been on the same version of xine-lib (1.2.2) - 0.99.6 and up to r3003 work (for Open -> File) with the shipped code, everything later that I've tested seems to find the status is XINE_STATUS_PLAY instead of XINE_STATUS_STOP. The following patch fixes 0.99.7 and current r3134 for me. --- xine-ui-0.99.7/src/xitk/actions.c 2011-09-11 02:37:46.000000000 +0100 +++ xine-ui-0.99.7.crazy/src/xitk/actions.c 2013-04-11 19:48:34.021703560 +0100 @@ -2145,7 +2145,7 @@ /* If an MRL is not being played, select the first file appended. If in "smart mode" start playing the entry. If a an MRL is currently being played, let it continue normally */ - if((first != gGui->playlist.num) && (xine_get_status(gGui->stream) == XINE_STATUS_STOP)) { + if((first != gGui->playlist.num) && (xine_get_status(gGui->stream) == XINE_STATUS_PLAY)) { gGui->playlist.cur = first; if(gGui->smart_mode) { gui_set_current_mmk(mediamark_get_current_mmk()); Clearly this isn't the right fix - moving the logos etc logically ought not to change the status within xine-lib - but for the moment it works around the issue. It also might not match the comment, I'm not sure I understood that. Attaching a copy in case it gets whitespace damaged, so that anyone who finds it can apply it if the problem remains open. Tested with : open file with mouse, open file from MRL browser, pass file name on commandline. There is also a minor issue - when I run xine without giving it a file, the window title says xine: There is no MRL. Technically, that is correct, but up to r3003 it just used to say xine: For that I don't really care, but I'll mention it in case it rings any bells. The bisection didn't make a lot of sense to me, so I tried moving forward to see if hte "no MRL" was a different issue or part of the same problem. Running the first few commits after r3003 was a bit messy - one or more commonly two popups saying there was no MRL - these appeared to refer to the logo! Skipping to r3020 put 'no MRL' in the title. Oddly, when I applied r3020 (only) on top of r3004 the functionality was restored and the popup no longer appeared. Unfortunately, doing the same thing on top of r3005 didn't restore the Open functionality. So, perhaps 3005 was the real culprit - but again it only replaced the splash .mpv logo with a png. I don't see how any of this could have changed the status in xine-lib, but (at least on my software stack) it did. Confirmation that the problem exists would be welcome. Denials and assertions that it is the product of my deranged imagination (currently very deranged after an all-nighter on this last night ;) will be less welcome, but I'll accept them if true 8) If confirmed, does anyone have any idea what is triggering this ? ĸen [ I see lots of the po files aren't UTF-8, so that is 'ken' if you can only handle ASCII ] -- das eine Mal als Tragödie, das andere Mal als Farce |
From: Petri H. <phi...@us...> - 2013-04-14 11:35:15
|
On pe, 2013-04-12 at 01:22 +0100, Ken Moffat wrote: > OK people, trying to subscribe to your -bugs doesn't work > (it doesn't mail the authentication, and it looks as if the > list might be defunct), and posting on -users got no response, > so now I'm here on -devel with a crazy patch to work around a > regression. > > I've been using xine-ui-0.99.7 for some time, but not very much. > Looking back, it seems I must have been on the commandline when I > tested it. Eventually I discovered that trying to open a file with > the right mouse button and Open -> File wasn't working. This is > on x86_64 linuxfromscratch, and I first noticed at the end of my > current desktop build - LFS-7.3 (still gcc-4.7 series), everything > else generally current released versions. > > As I noted on -users, on LFS we have current autotools. To run > autogen.sh I need to do > sed -i 's/AM_CONFIG_HEADER/AC_CONFIG_HEADERS/g' configure.ac > > I also had a couple of other old seds which I'm happy to > say are no longer needed in current hg : my comment on -users > saying we did still need one was wrong, but it appears to do no > harm [ I've just retested 0.99.7 without my patch below and without > the seds, it is definitely broken ]. And I did need them for 0.99.6 > when I was bisecting. > > At first I thought this might be down to using libpng-1.6, but when > I checked an older LFS-7.2 build from a few months ago I realised > that it too wasn't working. > > There is a blog post about this, > http://slackblogs.blogspot.co.uk/2012/09/xine-ui-reverted.html > but I couldn't find anything else relevant. > > I guess most people either pass the filename on the command line, > use the MRL browser, or use a desktop environment ? > > Or does anyone have a version of xine-ui-0.99.7 or current hg where > you can open a file with right-click, Open, File and it works ? If > so, what architecture and distro or system are you using ? > > Before I posted on -users I cloned the hg repository and bisected. > That told me that r3004 (allow jpeg for splash and logo, move the > splash and logo down a source dir) was the first bad commit. That > seemed impossible. > > Since then I've spent a lot of time instrumenting 0.99.7 and 0.99.6 > to find out what changed. In the end, I discovered that, apparently > for all versions since r3004 (but only fully tested in 0.99.7 and > r3134 which is the current version) the status of the stream has > somehow changed. > > This, I believe, is impossible - as far as xine-ui is concerned, > it's an opaque and incomplete data type. But all my testing has > been on the same version of xine-lib (1.2.2) - 0.99.6 and up to > r3003 work (for Open -> File) with the shipped code, everything > later that I've tested seems to find the status is > XINE_STATUS_PLAY instead of XINE_STATUS_STOP. > > The following patch fixes 0.99.7 and current r3134 for me. > > --- xine-ui-0.99.7/src/xitk/actions.c 2011-09-11 > 02:37:46.000000000 +0100 > +++ xine-ui-0.99.7.crazy/src/xitk/actions.c 2013-04-11 > 19:48:34.021703560 +0100 > @@ -2145,7 +2145,7 @@ > > /* If an MRL is not being played, select the first file appended. If in "smart mode" start > playing the entry. If a an MRL is currently being played, let it continue normally */ > - if((first != gGui->playlist.num) && (xine_get_status(gGui->stream) == XINE_STATUS_STOP)) { > + if((first != gGui->playlist.num) && (xine_get_status(gGui->stream) == XINE_STATUS_PLAY)) { > gGui->playlist.cur = first; > if(gGui->smart_mode) { > gui_set_current_mmk(mediamark_get_current_mmk()); > > Clearly this isn't the right fix - moving the logos etc logically > ought not to change the status within xine-lib - but for the moment > it works around the issue. It also might not match the comment, > I'm not sure I understood that. Attaching a copy in case it gets > whitespace damaged, so that anyone who finds it can apply it if the > problem remains open. > > Tested with : open file with mouse, open file from MRL browser, > pass file name on commandline. > > There is also a minor issue - when I run xine without giving it a > file, the window title says > xine: There is no MRL. > Technically, that is correct, but up to r3003 it just used to say > xine: > For that I don't really care, but I'll mention it in case it rings > any bells. > > The bisection didn't make a lot of sense to me, so I tried moving > forward to see if hte "no MRL" was a different issue or part of the > same problem. Running the first few commits after r3003 was a bit > messy - one or more commonly two popups saying there was no MRL - > these appeared to refer to the logo! Skipping to r3020 put 'no MRL' > in the title. Oddly, when I applied r3020 (only) on top of r3004 > the functionality was restored and the popup no longer appeared. > > Unfortunately, doing the same thing on top of r3005 didn't restore > the Open functionality. So, perhaps 3005 was the real culprit - but > again it only replaced the splash .mpv logo with a png. > > I don't see how any of this could have changed the status in > xine-lib, but (at least on my software stack) it did. > > Confirmation that the problem exists would be welcome. Denials and > assertions that it is the product of my deranged imagination > (currently very deranged after an all-nighter on this last night ;) > will be less welcome, but I'll accept them if true 8) If confirmed, > does anyone have any idea what is triggering this ? I think this all makes sense. Replacing .mpv logo with .png logo really triggers this. I think video streams are played to the end and status is changed to STOP, but image streams do not trigger status change (stream never stops). This is to avoid replacing image immediately with logo; if stream would stop one couldn't see the image. This is easy to test with any image file. Image is shown until user clicks stop. With video files xine logo appears immediately when the stream ends. Launching xine with any image from command-line also makes open dialog non-functional. Even worse, xine-ui crashes if one clicks stop after trying to open a file with open dialog ... > ĸen [ I see lots of the po files aren't UTF-8, so that is 'ken' if > you can only handle ASCII ] > ------------------------------------------------------------------------------ > Precog is a next-generation analytics platform capable of advanced > analytics on semi-structured data. The platform includes APIs for building > apps and a phenomenal toolset for data science. Developers can use > our toolset for easy data analysis & visualization. Get a free account! > http://www2.precog.com/precogplatform/slashdotnewsletter > _______________________________________________ xine-devel mailing list xin...@li... https://lists.sourceforge.net/lists/listinfo/xine-devel |
From: Torsten J. <t....@gm...> - 2013-04-15 13:13:39
Attachments:
xine-ui_open_file.diff
|
Hello! > OK people, trying to subscribe to your -bugs doesn't work > (it doesn't mail the authentication, and it looks as if the > list might be defunct), and posting on -users got no response, > so now I'm here on -devel with a crazy patch to work around a > regression. Hehe how nice to hear from somebody who shares my style of talking (have you ever read the Amiga Guru Book?). :-) > Eventually I discovered that trying to open a file with > the right mouse button and Open -> File wasn't working. Well, all you needed to do is to hit the >| NEXT button or to open the playlist editor, and you would know where all your attempts went. The real reason is turning the XINE logo screen from a motion video into a plain still image. Unlike AV, images are meant to play always and forever to let an average living room user zap through his photo album. Your patch perhaps breaks intentional playlist appending, and it will fail as soon as someone decides to use a video logo again. Maybe it is a better idea to make an exception for just the logo if a still image. [xine-ui_open_file.diff] open user file immediately when only logo is playing > This is on x86_64 linuxfromscratch, and I first noticed at the > end of my current desktop build - LFS-7.3 > (still gcc-4.7 series), everything else generally > current released versions. > > As I noted on -users, on LFS we have current autotools. To run > autogen.sh I need to do > sed -i 's/AM_CONFIG_HEADER/AC_CONFIG_HEADERS/g' configure.ac Dont say that too loud - they might "fix" it by breaking build on my old box... Torsten |
From: Ken M. <zar...@nt...> - 2013-04-15 17:39:32
|
On Mon, Apr 15, 2013 at 03:13:32PM +0200, Torsten Jager wrote: > Hello! > > > OK people, trying to subscribe to your -bugs doesn't work > >(it doesn't mail the authentication, and it looks as if the > >list might be defunct), and posting on -users got no response, > >so now I'm here on -devel with a crazy patch to work around a > >regression. > > Hehe how nice to hear from somebody who shares my style of talking > (have you ever read the Amiga Guru Book?). :-) > LOL. No, but I had contact with Amiga linux users in the days of the [ expletive deleted ] AmigaOne. > >Eventually I discovered that trying to open a file with > >the right mouse button and Open -> File wasn't working. > > Well, all you needed to do is to hit the >| NEXT button or to > open the playlist editor, and you would know where all your > attempts went. > > The real reason is turning the XINE logo screen from a motion > video into a plain still image. Unlike AV, images are meant to > play always and forever to let an average living room user zap > through his photo album. > > Your patch perhaps breaks intentional playlist appending, and > it will fail as soon as someone decides to use a video logo > again. > > Maybe it is a better idea to make an exception for just the > logo if a still image. > > [xine-ui_open_file.diff] > open user file immediately when only logo is playing > Tested on 0.99.7, passes the same tests I used before. Thanks to you, and to Petri, for the explanations. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce |