The origin of the project is a exercise in school where we had to make a PHP based database application. This is a common exercise in school for this topic. Also if the task "create a database solution for managing DVDs stored in a
cabinet" is a bit oldschool nowadays. But at this time the exercise was the basis for the project.
But MediaDB is more as the exercise of the school. It is made to manage all of the music or video collection. It makes no diffrence as in which kind of media (as files on disk or CD) they exist. For the diffrent possibilities of
"storing" them it is free to setup options for them. It is possible to make the diffrence between the media is a audio CD or a folder anywere on a hard disk. Also duplicate existing media can be handled from the system. One other
thing is that if some albums were merged onto a data disk, the disks acan also been added to the database.
Before I had MediaDB, I had all data about my CDs, which were stored in the cabinet, wrote in a Excel sheet. I made it in the same way for CDs and DVDs which I had to use on the computer. The idea to write all about my medias into a table came from my father. He made it with a grater collection in the same way. But over the time there were different Excel files which contained different data. In the past, when I was a little child, there were also medias like cassettes and radio plays. But after a time they were removed from the tables which were active managed. I had the interest to have access to those tables at many places were the media was stored. So one way is to print out the whole table. But is difficult to refresh it and annoying. Alternative put some displays next to the places were the media is stored and show the tables on them. But with a Excel file, which should be edited, it not a good idea. So as the noted exercise above was a good template, I thinked about create a webapp for it. But there was another point. The tables of my father. They are very big and so it is a bad job to refresh them. He would all time print them and hang them into the inner side of the cupboard doors. But he done this to lazy so they were never up to date. Also this was one thing which should be replaced by the development of MediaDB, including the printouts. So it were then easier to manage the data and maybe print the tables out.
When I thought about the access to the tables netx to the location of the media I also thought about the display of the website on a mobile device. The first idea was to place a smart display to each location. An other idea was to view the
website on a mobile phone. This is a handy way to search for details when the user is next to the location.
Also there was a extra problem. While the tables of my father should be replaced, it was a requirement that my mother must- and be ablte to use it. She already complains about the old not updated wall tables of my father. Then it comes to
the event that we buyed a CD twice, as nobody knows, as it is already there.
To be able to see the data on a mobile phone was a very important point, so for example my mother can use the application.
So I made the web views ready to be displayed on small displays. Unfortunately at this time my skills in CSS were at a very beginner level. So you can find there some re- definitions, which makes it not good maintainable. But starting with
HTML5 and the JS extensions I improve them.
MediaDB-Tool is an extension for the computer. It is not a sencond client for display the stored data. It is made as a tool to import data into the database.
The source for the idea has it's own background. Nowadays you often buy albums of interprets online so they are stored as files on a hard disk. Now it is no big thing to just add the entry for the new album to the database all by hand. But
you maybe also want to store the title list in the database. It is also possible to add them using the web interface. But it is very exhausting to do this by typeing the name of any title of the album into the web interface. Also the length
of the title names make this work more exhausting. But as the files on the hard disk mostly already have the name of the title (sometimes also interpret and number) in the file name, it might be easier to transfer the file names into a
title list.
A second background to create this tool is the big collection of discs of my father. My father already tried to list all of them in a Excel table. If now the tables from him should be migrated to the database, it is also an exhausting job.
So I planned to make it possible to let the MediaDB-Tool go through the tables and migrate the contained entries into the database. When it is done then it not so hard to fix some missing albums or add missing tracks.
The application must run on a PC, as it needs to access the filesystems. I wanted to make the tool for Linux or uniplattform, but the tool must be usable for my father or my mother. Every body has a Windows PC. So I decided to build the
tool using Visual Studio in Visual Basic.
The tilte list of file names feature was the first I made for the tool. Before useing it, the album must be added at first to the database of MediaDB. The this ablum is just choosen in the tools list display. In the title grid then maybe existing titles are displayed. The grid won't be filled if there are no title added jet. Now there is a menu where you find "Title aus Dateinamen ableiten" (ENG: "Get title names from file names"). In the following form it is needed to select the path where the files are located. All files there will be load into a list of the form. It is than possible to particular select them or all. In the field below the user put in a formatting string. Using the in this field written format blocks the programm will later use them to parse the names into the list below. These formatting blocks can be added by click on the labled templates in the form. Doing that some extra parameters for the bock will asked to fill in the block with the wanted setting. As of the moment the user clicks on the "Dateien parsen" (ENG: "Parse file names") button, the application goes through the file names and splitt them into the title list in the grid. When it is done, it is possible to change the results as needed. By a click on "Übernehmen" (ENG: "Apply") it will transfer the title list into the database. Then you will see the title list in MediaDB.
In the past I lerned PHP in school and started to use it to develop MediaDB. The usage of the database is not bad when using PHP, but after a time I don't like it so much anymore. My problem was that to have the data in the user interface
it was everytime needed to inline load the data from the database, do something with it and write them in the HTML output.
Yes, of course it also were possible to make a HTML raw document, which fetches JS code, then fetches the data and puts it into the HTML blocks. But at this time I never had practice JS programming. And from the point of today, I have to
say, that I don't like this kind of practice and would not like to use it for this project.
The use of PHP had every time a major problem. As I had the need to make the most of the HTML code by the output of PHP, I had to mix it with the use of getting the data from the database. If an error occours then PHP kills the whole
process which was at first bad for the database. The browser got then just a uncompleted HTML (which destroys the view of the page) or a blank result back. Where the problem was I can only find out by checking the servers logfile. Sometimes
also by testing line per line of my mixed code.
In the last time I had at my studying a course where we lerned something about web development. There were diffrent parts (one were we had for example something about CGI applications) to at least the use of web frameworks. We had a
overview about diffrent frameworks based on diffrent programming languages to a deeper use of the Flask framework based on Python.
Also in this part we made some exercises were I lerned how to use Flask for development. I checked out some other frameworks, but I wanted to use Python. In Python I had first experience in programming and the connect to the database. So I
choose to stay on using Flask.
I like the method as I develop the application. I also like that there is no mixing of the codes. Anything which should be HTML is made as bare HTML and the work of collecting the data is done on the side of the Python code. So now I had
ported MediaDB from a PHP app to a Python (Flask) based app.
MediaDB has diffrent types of list views. So it is possible to show media separated from other media. Also it is possible to click on the name of an interpret and switch to a list of all media of the clicked interpret name. The lists are linked to each other as possible. Some of them are accessible every time by a button on top of the page. Of corse you can also view closer information details about media. Also a there are list views depending on which media has a location attribute.
For the purpose to view the contained albums on a data disk for example when the actual view is a table of stored media, it is possible to view this information just with a click on a button. This information is shown as a modal view (second layer) in the browser. So you can fastly get a view wich media is linked to each other. Also the user can here switch to the detailed view of the medium.
As the fist search feature I made the simple search. I mean the little search bar at the top of the page. It is possible to search for any audio or data disk by it's name. Here it is not possible to search or filter for the media's interpret. Thierfor there is the button for the extended search. The matrix search offers the searching for the combination of interpret and audio / data disk. It is here possible to search by fill in only one of the options or use mutiple of them. Also here it is possible to search for the name of a title. The the options extend to a triple combination.
It is possible that you store your CD's in the cabinet in boxes or etuies. Of corse, this is not possible with digital media. But for having the real view were exactly the discs arre located, it is possible to go from location based list to the slot viewer. In this view you can "virtual" see the position of the cases in the storage location and place them into the slots. The media then will occupy the required slots as the defined width of the store type (e.g. a 1CD case). This types of storeages are called "Media Container". They have a fixed amount of slots. A slot is defined as the width of a small disk case which is often used for singles. So this value defines the maximum of slots which a Media Container can have. These setting are done at the Media Container. The "width" of a store type is set for all store types. This is by default minimum 1 like a small single case. A common CD case will occupy the double space as the single case does, so the width is 2. So in the slot viewer such a media case will occupy two slots, means 2 table rows. So it is possible to have a look if a new CD with a case can fit in free slots of the media container or not.
On all media which is added to the database you may want to have a closer look into the details of it. If someone clicks in the table view on the name of the medium, it opens the detailed view. Here you can see more details which can not shown in the table, because the isanot enough space. For CDs her you also can see the length and the type of disk it is used. For data disks you here see the contained albums. On the other side you see in the albums on which data disks they are included. For the ablbums which are stored on a hard disk you will here see details like the path were they are stored. Al detail views allow directly to change the data of the medium. Also from here it is possible to envoke the removal of the entry.
One second detail on the detailed view is the title list. It is displayed on all albums. It is possible to add new title from here or after adding the album. (Or the user will use MediaDB-Tool to import the title list from there.) Every title can have it's own interpret. If the user saves the original position of the title, the list will be sorted using the position. The length of the title were not saved, because they were not of my interest.