Bug 494505

I never had a chance to actually test this on rawhide, as I don't have a rawhide box.

Will: any ideas?

Wow--that's got to be a really annoying bug.  I'll try to look into this in the next couple of days.

What's rawhide right now?  Is that what will become Fedora 11?

(In reply to comment #2)
> Wow--that's got to be a really annoying bug.  I'll try to look into this in the
> next couple of days.
> 
> What's rawhide right now?  Is that what will become Fedora 11?  

Yes, exactly.  Rawhide is now in freeze, awaiting a final compose of packages.  Although if we could identify the problem and fix this very soon, we could request that the updated Miro be added to the final package list GA (general availability).  Otherwise it would have to wait for a post-F-11 update.

I haven't been able to reproduce the issue.  It'd help to know what steps Rudd-O used to bump into the problem.

Having said that, I have a possible blind fix, but I don't know if it fixes the problem.  Attaching it in the next thing.

Created attachment 342648 [details]
blind fix that might fix this issue

This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

(In reply to comment #5)
> Created an attachment (id=342648) [details]
> blind fix that might fix this issue  

Is this fix in 2.0.4?  I just did a build of 2.0.4 on F-11 which is about to be pushed to updates-testing:

https://admin.fedoraproject.org/updates/Miro-2.0.4-1.fc11

Can you still reproduce this bug with the latest Miro (2.0.4-1.fc11) with a clean config?

YES

----------------------------------------------------------

2009-06-30 12:28:09,201 INFO     Starting auto downloader...    
2009-06-30 12:28:09,203 TIMING   Icon clear: 0.000              
2009-06-30 12:28:09,203 INFO     Starting movie data updates    
2009-06-30 12:28:09,205 INFO     Checking for updates...        
2009-06-30 12:28:09,507 INFO     failed() called; generating crash report.
2009-06-30 12:28:09,510 INFO     ----- CRASH REPORT (DANGER CAN HAPPEN) -----
2009-06-30 12:28:09,511 INFO     App:        Miro                            
Publisher:  Participatory Culture Foundation                                 
Platform:   gtk-x11                                                          
Python:     2.6 (r26:66714, Jun  8 2009, 16:07:29)  [GCC 4.4.0 20090506 (Red Hat 4.4.0-4)]
Py Path:    ['/usr/bin', '/usr/lib64/python2.6/site-packages/gst-0.10', '/usr/bin', '/usr/lib64/python26.zip', '/usr/lib64/python2.6', '/usr/lib64/python2.6/plat-linux2', '/usr/lib64/python2.6/lib-tk', '/usr/lib64/python2.6/lib-old', '/usr/lib64/python2.6/lib-dynload', '/usr/lib64/python2.6/site-packages', '/usr/lib64/python2.6/site-packages/Numeric', '/usr/lib64/python2.6/site-packages/PIL', '/usr/lib64/python2.6/site-packages/gtk-2.0', '/usr/lib/python2.6/site-packages', '/usr/lib/site-python']                           
Version:    2.0.4                                                                                                                   
Serial:     20090329000                                                                                                             
Revision:   https://svn.participatoryculture.org/svn/dtv/tags/Miro-2.0.4/tv/resources - 9360                                        
Builder:    mockbuild.phx.redhat.com                                                                                   
Build Time: 1245305527.51                                                                                                           
Time:       Tue Jun 30 12:28:09 2009                                                                                                
When:       Calling <bound method HTTPClient.callbackIntercept of <miro.httpclient.HTTPClient object at 0x7fbdcc1e1390>> on <class 'miro.httpclient.HTTPConnection'> -- closed                                                                                          

Exception
---------
Traceback (most recent call last):
  File "/usr/lib64/python2.6/site-packages/miro/trapcall.py", line 42, in trap_call
    function(*args, **kwargs)                                                      
  File "/usr/lib64/python2.6/site-packages/miro/httpclient.py", line 1618, in callbackIntercept
    response = self.prepareResponse(response)                                                  
  File "/usr/lib64/python2.6/site-packages/miro/httpclient.py", line 1670, in prepareResponse  
    response['filename'] = self.getFilenameFromResponse(response)                              
  File "/usr/lib64/python2.6/site-packages/miro/httpclient.py", line 1804, in getFilenameFromResponse
    return filenameFromURL(util.unicodify(response['redirected-url']), clean=True)                   
  File "/usr/lib64/python2.6/site-packages/miro/util.py", line 454, in checkFunc                     
    result = func(*args, **kwargs)                                                                   
  File "/usr/lib64/python2.6/site-packages/miro/download_utils.py", line 190, in filenameFromURL     
    return unicodeToFilename(u'unknown')                                                             
  File "/usr/lib64/python2.6/site-packages/miro/util.py", line 414, in checkFunc                     
    result = func(*args, **kwargs)                                                                   
  File "/usr/lib64/python2.6/site-packages/miro/plat/utils.py", line 167, in unicodeToFilename       
    filename = shortenFilename(filename)                                                             
  File "/usr/lib64/python2.6/site-packages/miro/util.py", line 400, in checkFunc                     
    checkU(result)                                                                                   
  File "/usr/lib64/python2.6/site-packages/miro/util.py", line 392, in checkU                        
    raise MiroUnicodeError(u"text %r is not a unicode string (type:%s)" % (text, type(text)))        
MiroUnicodeError: text '' is not a unicode string (type:<type 'str'>)                                

Call stack
----------
  File "/usr/lib64/python2.6/site-packages/miro/trapcall.py", line 42, in trap_call
    function(*args, **kwargs)
  File "/usr/lib64/python2.6/site-packages/miro/httpclient.py", line 186, in trap_call
    return trapcall.time_trap_call("Calling %s on %s" % (function, object), function, *args, **kwargs)
  File "/usr/lib64/python2.6/site-packages/miro/trapcall.py", line 42, in trap_call
    function(*args, **kwargs)
  File "/usr/lib64/python2.6/site-packages/miro/httpclient.py", line 186, in trap_call
    return trapcall.time_trap_call("Calling %s on %s" % (function, object), function, *args, **kwargs)
  File "/usr/lib64/python2.6/site-packages/miro/trapcall.py", line 47, in trap_call
    signals.system.failed_exn(when)

Threads
-------
Current: Event Loop
Active:
 - ThreadPool - 0 [Daemon]
 - ThreadPool - 1 [Daemon]
 - ThreadPool - 2 [Daemon]
 - MainThread
 - Movie Data Thread [Daemon]
 - Event Loop

2009-06-30 12:28:09,511 INFO     ----- END OF CRASH REPORT -----

----------------------------------------

This is outrageous.  How is it even possible that this bug persists without any fix?????????  This is PYTHON, not assembler!  Tell the Miro devs that they really do not care about their users.

this app is a disaster internally, EVERYWHERE in download_utils.py, exceptions have been silenced with except: pass.  it's no wonder that it malfunctions and gives out BULLSHIT exceptions.

tell the developers they win an internet busey clap.

(In reply to comment #10)
> this app is a disaster internally, EVERYWHERE in download_utils.py, exceptions
> have been silenced with except: pass.  it's no wonder that it malfunctions and
> gives out BULLSHIT exceptions.
> 
> tell the developers they win an internet busey clap.  

I understand your frustration, however this isn't too very helpful in getting assistance from upstream.  If you have issues with upstream, you should contact them directly rather than ranting on a distro bug report.

Will: can you reproduce this?  I will try as soon as I have upgraded to F-11.  I suspect it also might be x86_64-specific.

Here is a patch that at least fixes one bug where an inner function within miro incorrectly assumes that it has been passed an unicode string when it is clearly not the case.  apparently the developers discovered decorators and decided "hey, decorators sound awesome, let's use them everywhere indiscriminately".

unfortunately, even with this patch, there is a shitload of gettext errors upon startup because the gui exception handler in miro is hooked BEFORE gettext is initialized.  and even after those are overcome or silenced, none of the feeds load -- they just display the loading icon, frozen.

and we are NEVER going to discover where the bug is, thanks to the liberal policy of peppering everything with except: pass.

this app is beyond fixing.

----------------------------------------

diff /usr/lib64/python2.6/site-packages/miro/plat/utils.py utils.py -urN
--- /usr/lib64/python2.6/site-packages/miro/plat/utils.py       2009-06-18 06:12:05.000000000 +0000
+++ utils.py    2009-06-30 18:17:44.000000000 +0000
@@ -130,9 +130,11 @@
     Note: This is not guaranteed to give the same results every time it is run,
     nor is it guaranteed to reverse the results of filenameToUnicode.
     """
-    @returnsUnicode
+    # @returnsUnicode
+    # who is the imbecile that would require this function to return unicode when clearly
+    # the 'last' variable can contain binary text because the supplied text can contain it too?
     def shortenFilename(filename):
-        checkU(filename)
+        # checkU(filename)
         first, last = os.path.splitext(filename)

         if first:

Like I said in comment #4, I'm not able to reproduce the issue.  It'd help to get a set of steps to reproduce.  Sounds like Rudd-O can reproduce it easily, but I'm not really sure what he/she is doing to do so.  It's possible that whatever caused this issue is fixed in trunk.


I do want to speak to the "upstream is a bunch of imbeciles" comments.  First off, you're right on--the try/except pass code in the codebase sucks ass, is inexcusable, and hasn't been re-written yet.

You're also right on with the gettext spam--it's fixed in trunk.

We've been rewriting large portions of the codebase with recent versions.  Miro 2.0 was a massive rewrite of the ui.  Miro 2.5 has a massive rewrite of data storage.  We've been cleaning up code, fixing documentation and PEP-8 issues, fixing unit tests, fixing build issues, and generally making the project better release-to-release.  That's where we're at.  I wish it were better, I'm working to make it better, but it probably won't be better faster without more help.

We'd love to get help from you and others.  If you can't contribute code, contribute testing work and/or funding.

If you really think it's beyond fixing, spare yourself the frustration and don't use it.  No piece of software is worth the level of frustration it sounds like you're having.  If you're an able programmer, you could probably write a program that has the important features of Miro that you use without the misfeatures in a week or two.

I commend you on the efforts you're making to fix it -- may I remind you that I could use Miro in earlier pre 2.0 releases fine.  Perhaps you have a PayPal address where I can send $50 or $100 in contribution to fix Miro bugs, with an attention to the bug I'm experiencing?  I know it's not much, but anything is better than nothing, and I'd be giving you access to the workstation where I'm experiencing the bug, so you can reproduce it and debug it in real-time if you so choose.  At any rate, the first thing to try, logically, is a trunk-release packaged as an RPM to see if that finally works, and if it does, then it'd be prudent to make a bug fix release.

My hunch is that this issue isn't related to chipset, but rather related to feed data.

Out of curiosity, has the patch in comment #5 been tried yet?  It's a blind fix in the sense that I can't reproduce the issue, but it sure seems like the fix should fix it.  It touches the same bit of code your patch in comment #12 touches, but the change is different.

As an aside, I get how this is infuriating and I definitely agree that parts of the codebase are a mess.  I apologize for both of those things--they suck.

Here is a pending Miro 2.5.2 update:

http://admin.fedoraproject.org/updates/Miro-2.5.2-3.fc11

Perhaps you could attempt to reproduce the error with a clean config.  It will go to updates-testing initially to get as much QA as possible before being pushed to stable.

Could the reporter indicate whether they can still duplicate with Miro 2.5.2 on either F-11 or F-12?  otherwise I will probably CLOSE as UPSTREAM, if there is an upstream bug that is tracking this.

No one has been able to reproduce or comment on this for 6 months, so closing bug.