Thank you for your donation!


Bulk saving/loading user-defined radio stations
#21
@gabeg

You have to follow the github instructions to install my Python script(s) on the new player. Then as the README says, "On the destination moOde player, ensure the myradios.tar.gz file is in the same directory as loadmyradios.py...." 

When I was developing and testing the scripts I just ran everything from the user pi's home directory.

Regards,
Kent
Reply
#22
So i've managed to get the file copied to my computer. How do I get the file from my computer copied to the destination player? I copied to the sdcard but don't know how to get it in the moode-radio-utils directory
Reply
#23
Getting the file back to the new moOde player is a matter of reversing the action taken to get it off (see my four choices).

Where to put it depends on where you installed my scripts.

Regards,
Kent
Reply
#24
(05-11-2020, 05:24 PM)TheOldPresbyope Wrote: Getting the file back to the new moOde player is a matter of reversing the action taken to get it off (see my four choices).

Where to put it depends on where you installed my scripts.

Regards,
Kent

I got it done!  Thanks for your help!
Reply
#25
Dear Kent, I was happy to find your scripts that you made to export added radio stations from an old moOde system in order to import them back in a new moOde.
The only thing is, and I believe I did everything correctly, I cannot import. The import process stops with an error.
The myradios.tar.gz is 1.8 MB in size and contains 33 .pls files in /RADIO, 28 .jpg files in /logos and 28 .jpg files in /logos/thumbs.
So not a massive list and I presume I could manually add everything back in some time.

I was exporting from moOde 6.4.0 so using your script 1.0 for that, and now use moOde 6.7.1 and of course used script 2.0 for the import.

Results in the ssh session:

pi@moode:~/moode-radio-utils $ chmod +x loadmyradios.py                                           
pi@moode:~/moode-radio-utils $ sudo ./loadmyradios.py
Load user-defined radio stations from myradios.tar.gz  in the current working directory      
Proceed? (y/n): y
adding station 'BLUE BOSSA NOVA'                                                                  
Traceback (most recent call last):                                                                
 File "./loadmyradios.py", line 114, in <module>
   entry['genre'],
KeyError: 'genre'                                                                                 
pi@moode:~/moode-radio-utils $

What could be remarkable, station BLUE BOSSA NOVA is 5th in the list.
So nothing is added to the Radio Stations.
Maybe this is of any help for smoothing the scripts.
I have added the file. Needs to be unzipped first in order to use.


Attached Files
.zip   myradios.tar.gz.zip (Size: 1.74 MB / Downloads: 0)
Reply
#26
@basmeyer

I see I didn't explain the script versions very well in my README.md. 

Basically the v1.0 scripts deal with moOde players (r5.3.1 to r6.5.2) which use a particular older database schema for the radio stations and work only with those players. The v2.0 scripts deal with moOde players (r6.6.0 to r6.7.1) which use a newer database schema and work only with these players. 

There is no attempt in the current scripts to migrate between the two schemas. This is why I said of the v2.0 scripts "[N]ot compatible with prior releases of moOde or with myfiles.tar.gz files created using v1.0." It's what I meant by "compatible" in the second possible use-case I listed: "[B]etween moOde players running the same or different, compatible moOde releases." 

The database schema is going to be different yet again in the upcoming moOde r7.0.0 so many folk with a large number of user-defined stations will soon face the same problem you do. 

Let me see if I can come up with a solution which eases some of the pain. Likely it will involve changing the save script to include a script version number in the saved myfiles.tar.gz dataset, changing the load script to check this against the moOde player release number, and adding code to migrate to the newer schema if need be.

This solution would work between players using the same schema, or between a player using an older schema and a player using a newer schema; no backsliding! The values in any new database columns will necessarily be left blank (or whatever is an appropriate default value) and will have to be filled in later using the manual station edit function. An example of this is the new "geo-fenced" entry which will appear in r7.0.0.

Regards,
Kent
Reply


Forum Jump: