Bug 141490

Summary:	quicktime ipod video (mp4 m4v mov) broken, xine engine?
Product:	[Applications] amarok	Reporter:	danny <dj>
Component:	Collections/iPod iPhone	Assignee:	Amarok Developers <amarok-bugs-dist>
Status:	RESOLVED DUPLICATE
Severity:	normal	CC:	matej
Priority:	NOR
Version:	1.4.5
Target Milestone:	---
Platform:	openSUSE
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description danny 2007-02-10 17:24:14 UTC

Version:           1.4.5 (using KDE KDE 3.5.5)
Installed from:    SuSE RPMs
Compiler:           compiled by guru for suse 10.1 and opensuse 10.2
OS:                Linux

After updating to amarok 1.4.5, the program no longer recognizes m4v, mp4 or mov files properly.  The problem seems to depend on the file extension:

m4v videos cannot be loaded onto the amarok playlist (with 'some media could not be loaded (not playable)').  They cannot transfer to the video ipod at all, returning 'track not playable on media device'.

mov files load onto the playlist, but can't transfer; just like m4v.
  
mp4 files load onto the playlist, but transfer to the ipod video as audio only.  

This bug occurs using the xine engine, although xine is perfectly capable of playing the files.  Yauapp gives the same problem; it won't load any .mp4 type files at all.  I have tried downgrading to previous versions, but the problem sticks with me.  

I use libgpod version 4.2-2, marked as the compatible version by my package manager.

If there's a quick fix for this, I'd love to hear it.  Thanks.

Comment 1 Mark Woodward 2007-02-13 22:13:59 UTC

Same problem here

Comment 2 Martin Aumueller 2007-02-19 01:58:52 UTC

Is your iPod type recognized correctly?  This should be visible in the media device selection combo box at the top of the media browser.

Comment 3 danny 2007-02-19 11:12:06 UTC

My ipod is recognized as ipod.  

I can manually set the specific model to xA450 (black, 80 GB) but this seems to have no effect on anything.  It still says that m4v's won't transfer because they are 'not playable.'  

I've tried this with both "Diggnation (ipod)" and "Geekbrief (ipod)" podcast files.  They are playable in xine, and ipod-loadable in gtkpod, so the problem is not the ipod or the videos.

Comment 4 Mark Woodward 2007-02-20 20:46:12 UTC

My ipod is also recognised correctly. I should also note that I'm using the official kubuntu edgy packages, not suse.

Comment 5 Mark Woodward 2007-02-24 15:54:36 UTC

I've been having a dig around and it looks like m_supportsVideo is never set to true. This seems to be because libgpod always thinks the ipod type is unknown, even when the ipod type is set manually through the menu. Hope this helps although I don't really know my way around amarok.

Comment 6 danny 2007-02-24 22:56:18 UTC

Hmm, I can't say libgpod is the problem, because gtkpod works fine with video transfers.  I've been using it to transfer stuff onto my ipod (although I'd rather use amarok because it sends the xml/itunes metadata to the ipod library).

Where is the m_supportsVideo value stored?  Maybe it's somewhere I haven't tried hacking around yet.

Comment 7 Mark Woodward 2007-02-24 23:34:18 UTC

the supportsVideo value is in the ipod media device class in amarok. I'm not suggesting that libgpod has any problem with video transfers, more that in some way amarok and libgpod aren't agreeing as to whether the ipod connected actually supports video transfers.

Comment 8 danny 2007-02-27 12:53:49 UTC

OK, that sounds right about disagreement between libgpod and amarok.

Unfortunately for me, for now, going in and tracking class values is a bit out of my, um, scope.  I've been using other software to manage my ipod, but I'll keep an eye on the latest suser-guru updates and see if I can get it to work.

Comment 9 michael shimogawa 2007-11-12 06:43:08 UTC

I don't have much to add, except that I have this problem as well. The model was set in the SysInfo file by gtkpod. I can see that Amarok has also identified it correctly (ipod nano video). I thought at first that it was because the old Nanos couldn't play video, but this seems more likely.

Comment 10 Martin Aumueller 2007-11-13 04:29:12 UTC

Already solved since 1.4.6.

*** This bug has been marked as a duplicate of 148607 ***