horst

A little change in the importer script has to be done: - added a line that prevents the Shellwindow from closing when the wrong username/password was provided. With the fix now it stays open and the user get the info. LocalAudioFilesImportShellScript.zip (is included in the above Version 1.0.5 now)

Local Audio Files - MP3-DB The Local Audio Files DB is a combination of a Module and a SiteProfile. It is intended to import MP3-files from your filesystem into ProcessWire, read ID3-Tags and pull coverImages from it to feed the DB. It is thought as a starting point for your own site creation. A sort of comfortable aggregated reuseable code for PW-lovers. How to Install Grab a copy of the latest ProcessWire. Replace the install, modules and templates directories with those in this profile, as shown below: /site-default/install/ /site-default/modules/ /site-default/templates/ With SiteProfile-Installs normally that is all there is to do. With this Profile you also have to copy the file LocalAudioFilesImportShellScript.php (for simplicity) to your PW-rootfolder, (where the index.php reside). If you are on Windows you also should copy mp3_import_starter4win.cmd to the same location. Now install ProcessWire as per the instructions included with it and it will install the LocalAudioFiles profile automatically. After that you find a Quickstart Guide at the homepage of the profile: Follow the 3 steps and you are done! How does it work? The Site has 4 sibling Tree Branches: genres - artists - albums - songs. Each of them hold child-pages: genre - artist - album - song. The logical relations are nested parent-children ones: a genre hold artists, each artist hold albums, each album hold songs. To support both, slim and fast data relations & the logical hirarchy, the module extends the ProcessWire variable $page with some additions. It uses the addHookProperty mechanism to achieve that. It uses an own caching mechanism for large lists, that can be prebuild when running the importer-shellscript, or it build the cache on demand. Also it comes with a FrontEndHandler class that provides a lot of functionality, for example fully customizable FormSelectFields of all genres, artists or albums. More detailed informations and code examples are collected in a demo section of the site. The extended $page variable together with the LocalAudioFiles-FrontEndHandler gives you comprehensive tools to work with your music collection. Download Modules Directory LocalAudioFiles-SiteProfile_v0.1.5.zip LiveDemo I have uploaded a small LiveDemo with only 7 truncated songs. But it's pretty fine to view all Demos and the additional $page->proterties. demo song page demo album page demo artist page demo genre page Graphical overview Screencast of installation https://youtu.be/-qYyppvEF1k History of origins http://processwire.com/talk/topic/3322-how-to-setup-relations-for-a-mp3-db-with-pw/ http://processwire.com/talk/topic/3462-pages-get-return-nullpage-but-page-exists/

I'm not totally sure but it seems that you can read the dBase file directly with PHP, so you will be able to read the records from the file and use the API to import them. http://php.net/manual/en/ref.dbase.php EDIT: here is a guy who has converted dBase to CSV: http://www.dev-zero.de/php/mit-php-dbase-zu-csv-konvertieren.html He uses a dbase class from another guy: http://www.dev-zero.de/downloads/dbf_class.php and the code to do the convert is short: <?php include("dbf_class.php"); // include the class $dbaseDB = ‘DB.dbf’; $dbf = new dbf_class($dbaseDB); // open the dBase file $csvFile = ‘file.csv’; // create a CSV file $csv = fopen($csvFile,"w"); // get record count, loop through and convert to csv $num_rec=$dbf->dbf_num_rec; fputcsv($csv, array_keys($dbf->getRowAssoc(0))); for($i=0; $i<$num_rec; $i++) { fputcsv($csv, $dbf->getRow($i)); } fclose($csv); // ready! now use Ryans CSV-Importer But want to note that I only have googled that and have not tested / used this by myself, so- no warranties ;-)

I have successful hooked new properties to the existing pages (parents: genre|artist|album) and (children: artists|albums|songs), and some more. With the demos I have made some progress, and I have made a graphical overview: Edit: new Mindmap

Oh! - Ok, why not!

current situation is as follows: With my MP3-DB I create extended page-objects that have some additional Properties and tweaked Children. Now I've thought if it would be better to use the 'real' $page variable for that. Extending it with some Properties could be done like explained in the Hooks-API-Doc: http://processwire.com/api/hooks/#add_new_property But, I need to tweak the $page->children and $page->childNum. Is there any chance to do that? ------------ why do i want this to have: if one is, for example on a album-page, the album-page has no children, because the DB-Structure has sibling branches for albums and songs. But human logic says an album must have children (the songs)

Hi <eagle eye>kongondo</eagle eye>, this would probably be useful to me too.

Hi, when surfin' to http://processwire.com/api/cheatsheet/ I only see blank page, whereas all other API-Docs are shown correctly. Can someone validate this please?

I think when hooking into page the event->object always is the page. $event->arguments is an array, and I would think that it holds the params like the original function you hook into. If you hook into function ___funcname($param0, $param1,$param2), I think you can get in your function $param0 = $event->arguments[0], $param1 = $event->arguments[1], ... EDIT: see: HookEvent #18 and following lines and see the new API-DOCs for Hooks #read_arguments! (and all above and below)

maybe it is a stupid question and it can be done with PW without worries, but I want to ask: can we call a field title, because every page/field in PW has already a title? (I've thought title is the only mandatory field for all pages in PW) EDIT: have just tried it and when save the new field I got: Field may not be named 'title' because it is already used by another field As I have tried this with a singular language page and a simple Textfield, this may be other when trying to create a multilanguage text field. Maybe one DB-Table could be created and the other one not, - but the Errormessage wasn't shown to the user. Just a thought, I'm PW-Newbie EDIT2: No, also with a multi language site I cannot save a field named title

Hi onjegolders, and Yes! And this one should work too, I believe, but without garanty: $page = $event->object; (I have seen this and used it by myself, and when hooking something with page, I think this will work.)

Hi Jason, as Ryan already said, there is not enough memory for PHP. And for those who are on a shared (Apache)-server and have no access to a php.ini file: you can try to set this line into the (root) .htaccess file: php_value memory_limit 256M or if this won't work: php_value memory_limit 128M

Ok, now I know what you mean ! first: it wasn't intended to use the filename as output in the frontend, (I never had thought that one want to do that). I provide stream-Urls for playing/downloading with the frontend-handler: echo $fe->streamurl(); // outputs something like: /stream/12345/song.mp3 whereas 'song.mp3' is an optional fake filename what is needed by Yahoo-Webplayer for example. Or you simply use "/stream/{$song->id}/". Has you used the FrontEndHandler with your code? - or have you done every thing without it? (I know there were no docs with it, but I've said that it is in a very, very early state, sorry ) second: I'm not shure about data-src, (but as you use $config->urls, I assume you want use an url with it), - would one not to have to url_encode the filename? - But anyway, I never would use filenames with it, but stream-urls. ------------ @kongondo: Oho, - this is an awesome Frontend! Very cool, - feature rich, - good design. And yes, when all is ready, there should be something like a tutorial or maybe a good screencast (like Joss described how to do it). But I'm at the very beginning with the project . There are lot's to do. Just the importer seems to be stable right now. And what is really needed is some documentation that ships with the SiteProfile. I write some points down here and include them into the site later: ------------------------------------------- LocalAudioFiles provide a FrontEndHandler ($fe) for different data, - allready prepared for most usage: streamurl, (provides partial-downloads! and directly starts playing) playlist generation as m3u or pls, objects like $page, (but they are not real PW-pages) for the current page, because as of the DB-structure an album hasn't children that are songs, but it is really usefull to have children (and also it is logical). So when calling the FrontEndHandler it creates automaticaly the object for the current page: $genre, $artist, $album, $song. The $genre has PageArray artists as children, the $artist has PageArray albums as children and $album has PageArray songs as children. $album and $song have cover as PageImage, so you can use it like $album->cover->width(200)->url the FrontEndHandler also provides fully customizable FormSelectFields. You can call them like $fe->getFormSelect('album') or $fe->getFormSelect('artists'), whereas if you use genre, artist, album - you get a SingleSelectField, if you use the plural, genres, artists, albums you get a MultiSelectField! the data for select fields, - or for any other complete list is retrieved from an own Cache, that makes it really fast, once the cache is created. (after importing files, there is an option to (re)build it, otherwise it creates itself on demand) Forms for playlists, also random ones, will be send as POST-Request to /playlist/m3u/ for retrieving a m3u-playlist and to /playlist/pls/ for pls-type.With fieldnames album|albums - genre|genres - artist|artists you have to send IDs. you also can send a single song or album id to /playlist/m3u/{$id}/ as a GET-Request, (or: /playlist/pls/{$id}/) and there are more things, ... I have to write down it all, but it will take some time. I have started to add a demo section to the site, - but there are some points that needs to be coded (CacheRebuild), there are others that needs to be rewritten (CharEncoding with different ID3-Versions). The Docs need to be written, (oh, yes - I've allready said that ), ... ... and when working/playing with it, I get new ideas for new things like a playing history (has to go into stream-code, where we have control how many of a song is played, maybe when 80% of a song is streamed it counts up 1), OR - oh, now that I have $song, $album, $artist, $genre I should rewrite the getDBinfo-Methods to have not arrays but objects too: $genres, $artists, $albums, within all page-types, or, or, or, ... (- help, - I'm pinched for time ). So, - I have to find a cut and provide a useful and good understandable siteprofile, but what has some allready known limitations, and (for shure) some unknown bugs . This will be the point when ID3-CharEncoding and CacheRebuild is done, besides some minor bugs I have allready figured out and on my list. All other stuff, I think I should start later. ------------------------------------------- Here are a screencast showing what the FrontEndHandler provides, including some examples of the DemoSection: https://youtu.be/LaIZ0mpfNew

Hi kongondo, that with the bitrates I have allready solved that way that I capture them rounded (to fit into the predefined). That with the filenames I don't understand. ?? But the actually code has changed a lot, comparing against the first version.

Ok, here are the list: AlbumCover-Import is done new field for BPM in Songs is done ImporterScript now asks the user for every Task to enter a yes or no: (done) optionally delete all Pages (reset DB) import Files- and Metadata import AlbumCovers recreate the complete CacheData ImporterScript also ends with a question for 'Enter' to avoid closing the shellwindow (done) ToDo: As of the different CharEncodings with ID3v2.3 and ID3v2.4 (I think these are the two most common today) I have to rewrite the core ID3Tag-Reading. Until now I've used 3.party-code for that, but to play save on a per-file or per-field basis with mixed ID3Tag-Versions it's better to rewrite this. Some minor things here and their After that I can upload a useful SiteProfile.

Hi, I think this isn't difficult, but it seems to be one of the best solutions because: assuming the subdomain and main-domain are running on the same server, you have may the exact identical environment for development- and public-site.

Hhm, I want to stay with seconds in DB-field because than one can easily calculate total times of albums, the whole DB or what ever. I think it could be done on the fly. I have allready included some sort of this into the frontend-class for that. to store both into the DB is much unwanted redundant data, Wanze would say No, it recognizes Tracks by filename and skip them when already in DB it calculates a checksum to recognize duplicate files stored at different places and it checks sanitized strings for artist / album / song, so it also detects duplicate songs where the ID3Tags are a (very) little bit different (lower/ uppercase) or when you have the same song in different Bitrates Also all tasks are logged into files in site/assets/log/SubFolder/ ...

Have read in wikipedia about BPM: Lazy Boys from Redmond

That's right. My bad, I have selected the wrong type. Will correct it with the update. 1) Will be done by the importer. Is allready prepared to run, but yet not enabled, because I first want to have all other stuff stable. BTW, what do you think is better: should I create a separate script what only import a cover for each album. It could be called automatically at the end of the importer script. Or should it better be together with the importer script as a single script? 2) Where is it stored? ID3v2 only, or could it be into ID3v1 too? Is it called bpm or BPM or BpM (maybe you can pm me a sample mp3 where it is set)

It was that thing with that a selector query for titles longer than 50 chars haven't found allready existing pages. After Soma has found the answer for that, I have rewritten that part, because the pages of type genre and artist have to be unique whereas the pages for albums and songs could have duplicate titles. This is working now. Gladly!

Ok, you are right. All the advantage is only for people who are allready use and know Firebug.

Oho! I have allready noticed that the (page) fields are not set correct. But I also have solved the importer problem. Should I wait with updating the Profile until you have checked that with the genre field? --------------------------------------------------------- I also have found some nice audioplayers: about Sounds in HTML-Pages: www.w3schools.comand some Players:yahoo webplayer audio.js SoundManager 2 awesome Demo another awesome Demo MediaElement.js -----------------------------------------------------------

I'm using Firebug with Firefox since a long time, - I don't have the need to (often) test Websites in different Browsers, but if I had the need to do that I would find this interesting: Firebug Lite: doing the Firebug way, anywhere. Compatible with all major browsers: IE6+, Firefox, Opera, Safari and Chrome Same look and feel as Firebug Inspect HTML and modify style in real-time Powerful console logging functions Rich representation of DOM elements Extend Firebug Lite and add features to make it even more powerful https://blog.getfirebug.com/2013/05/02/future-of-firebug-lite/

Never heard about Andrew Duhon "The Moorings", but now I [ listen to | like ] it, (- and of course you can call me modest)