Bug 215126 - Podcasts not saved after reboot of Amarok
Summary: Podcasts not saved after reboot of Amarok
Status: RESOLVED NOT A BUG
Alias: None
Product: amarok
Classification: Applications
Component: general (show other bugs)
Version: 2.2.1
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: Amarok Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-11-18 15:53 UTC by manchette
Modified: 2009-11-29 19:50 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description manchette 2009-11-18 15:53:35 UTC
Version:            (using KDE 4.3.1)
OS:                Linux
Installed from:    openSUSE RPMs

I noticed a problem managing podcasts in Amarok 2.2.0 and Amarok 2.2.1 :

Podcasts saved are available and ok, in playlist , able to be read, but when you turn off Amarok only are left the podcasts in the playlist. The ones saved are not there anyymore.

I tried to save them again, turned off and then on Amarok ... and off they went again .

How come ?

Thanks ;)
Comment 1 manchette 2009-11-18 15:54:41 UTC
~> amarok --version
Qt: 4.5.3
KDE: 4.3.1 (KDE 4.3.1) "release 6"
Amarok: 2.2.1
Comment 2 Myriam Schweingruber 2009-11-18 19:46:32 UTC
You need to do a full collection rescan if you are new on 2.2.1, then restart Amarok to get a new database. Without a well running database it's not possible to see the saved podcasts.

This definitely works here. Don't worry about the different name of the bug I mark this a duplicate of, the reason is the same.

*** This bug has been marked as a duplicate of bug 214599 ***
Comment 3 manchette 2009-11-18 21:40:12 UTC
I tried this before mentionning it here :

1- i created a database with mysql following what i found in google with "amarok" and "mysql" : Mysql setup howto here http://amarok.kde.org/wiki/MySQL_HowTo

2-I then set up amarok options : using external mysql database enabled, server being localhost and port 3306 ; database being amarok, user being amarok too, and the password. 

 3- When i scan my /stockage1/musique music dir i do not have any collection saved in amarok . I tried another dir : /stockage3/musique : still nothing  in the collection. 
Shut down amarok, turned it on again , nothing better.

Tonight : 

Just saw taht runlevel of mysql was not on ... i turned it on , reboot of pc and a complete rescan of collection did not give me back my tracks. 

In local collection menu i can't see any tracks, in fact i have 1 track on local collection on localhost , clicking on the HD icon does not allow to see which track it is.
Is there something else i need to do to see my tracks and podcasts ? 
Thanks :)
Comment 4 Myriam Schweingruber 2009-11-18 22:05:56 UTC
Hm, I use mysqle here, and it works, so this could be related to you using an exernal database, but that is not my speciality. Reopening.
Comment 5 manchette 2009-11-20 10:42:00 UTC
I used the Amarok 1.4 way to build an mysql database, is this what's wrong ?


I don't understand what you mean by "this could be related to using an external database" :

In Amarok the setup/database menu is available only is the box "use an external database" is checked.
It also mentions that the user, database and access rights have to exist already, which is what i did.
Comment 6 manchette 2009-11-20 12:18:25 UTC
Hi, after discussing on #amarok irc chan i now understand i was not needing an external data base. I used to do so besause of sqlite neing too slow in amarok 1.4.

2 things i notice :

1-- It should be said out loud that Sqlite is not used anymore in Amarok 2 but Mysql instead .
This from scratch without any need for the user to change anything . 
Thus sqlite inconvenients on big collections are no more and no need to use external database but for specific needs alone.

2-- Then the "use an external mysql database" is confusing
YOu should there explain why is an external database needed.

On note on this has been added at the forum
Comment 7 Bart Cerneels 2009-11-29 19:50:02 UTC
This seems to have been caused by external database "adventures". Properly configured systems don't have this problem.