Regression in xine-ui-0.99.7 : Open File doesn't work

 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

------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/xine-devel

Origin: self <[email protected]>
Description: allows Open -> File to work on r3004 and later.
There is at the moment no logical explanation for how those changes
in xine-ui could affect the opaque status which is determined
within xine-lib, but the fact remains that running xine-lib-1.2.2
xine-ui-0.99.6 is fine, but 0.99.7 of any version from r3004 up
to the current r3134 fail to open files in this way.

 NB opening from the MRL Browser, or when a file is passed to
xine, work fine both with and without this patch.

--- 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());