sveetch / django-deovi Goto Github PK

• There is currently no validation, if given slug is something like "Plip plop's plap", there will be an exception from Django, which is not very nice.
• The command should have an option to fill the title when creating a new device.

This leads to error on tree view since we don't pin bigtree but with last version pandas is not installed anymore but we rely on it in tree view code.

We need to change requirement to:

bigtree[pandas]

There is actually no way to detect for removed directory when loading a Deovi dump.

Dump loading is able to see for creation or change on directory item. But if a directory is removed from a device source, the Deovi can not determine for a removed item and so can declare it into the dump. When the dump will be loaded, the removed items will still remain in the device collection.

Since Deovi can not really determine for removing because it does not have any history to relate on, this should be implemented at django-deovi level. When loading a dump it may be able to see for existing directory that are not in the dump and assume it has been removed and remove it from db (with a optin/optout option) with its possible related medias.

Note that mediafiles are managed differently and at this time i suppose removed mediafiles are properly removed from db entries, but it need to be validated.

Once loader command is fully ready, we can start to develop the major goal of this application which is to browse the loaded videotheque.

It is not clear yet if there will be the needs of a Javascript frontend or if HTML views will be enough for an enjoyable and useful experience.

At least to start we will create HTML views and we will be able to determine if it will be enough or not.

A very useful feature to compute the total size from selection.

Device, Directory and MediaFile details HTML should store the real size in byte in some attribute. Each item in list from a detail will have a checkbox (whatever its form), and each time we select a checkbox it update a "total size" widget somewhere.

A Django command named "devices" which should be able to list all existing devices from database and should output something like this:

Found 3 existing devices:
- [foo-bar] Foo bar (2 directories)
- [hello-world] Hello World! (42 directories)
- [plop] Plop (0 directories)

This is useful when using the loader command to search for available slugs without to start server, just directly from a command line.

And add a notice somewhere (command help?) that the slug is in between brackets.

Also for when there is no device yet:

There is not any registered device yet.

Everything should work from 3.8 to 3.10, we just need to update tox config to validate support.

A basic frontend with a Bootstrap base.

For now it is not decided yet if we will do parts with some modern Js lib like vue, alpine, etc.. At least we start with HTML screens to mockup the needs.

A simple new command "flush_medias" that will remove all directories and their mediafiles for a given device slug.

This is would be useful for user which just want to reset et recreate everything from dumps.

Currently there is no static included in application.

It means user need to dig in frontend to find Sass source to include in its project Sass source to build Django Deovi CSS styles or worse developing the CSS itself.

It has be seen than current styles are really tied to the Bootstrap theme used in Django Deovi Sass sources. Including the styles in a blank project with default Bootstrap is not very nice since it include occurences to the theme color instead of variables.

Also, the JS part is not available since it live in a JS component include in sandbox JS.

Finally, all these assets may be included in app statics, at least the JS one.

Django Deovi should avoid to introduce fields that are only edited from the admin instead of Deovi dump.

The most relevant example is that dump cannot reflect directories/files movements and deletion. This will probably painful to manage when changing these things on device and also in the admin each time.

So it seems that the Deovi dump should be the most recommended way to manage all changes, so the user can simply flush all data and just import an up-to-date dump.

So we should list some improvements in Deovi that Django Deovi could then implement.

Here is a starting list:

• The "device" concept, currently Deovi does not have any, it just collect directory with files from a given basepath;
• Discovery of directory manifest. Manifest will be a "manifest.json" file inside the directory where we can store informations to collect and store in django deovi database, like a real title, tags, etc.. Just to start the title will be enough;
• Directory thumbnail discovery, by default it will search for a "cover.jpg" or "cover.png" file, manifest may be able to specify another filename or path to search for;
• Some metadata from video media like time, encoding, bitrate, resolution, keywords, shutil.disk_usage, etc..

When Deovi will create a dump, it will have to base64 the image content to store it in JSON. This will be nasty to read in JSON and will produce bigger dumps but at least the dump will self sufficient and no image file will have to be transported.

It seems useless, currently not used and frontend is pretty basic without any UI/UX so we should serializer, routeur and viewsets.

Some fix and changes have been made to resolve issue with dumped covers and add some features.

List of things to adapt:

• Cover item won't be a tuple anymore, it will only be the relative file path sveetch/deovi#5

MediaFile have to be related to a Device object to improve organization.

Add a command to flush all MediaFiles and possibly Devices, for possible case when we need to fully reboot our videotheque and mostly for some development testing.

The device object should have a date to update on each new dump loading to be able to know the last dump load.

When load perform edition bulk chain, it just edit all found existing files from dump. It does not attempt to find if they have changed or not, just fully edit them.

This have performance issue, also it will update file storage date for nothing.

The 'DumpLoader.edit_files' method should compare the existing object again the dumped one to check that there is at least a change to trigger an edition or just ignore it. Logs will have to notice about effectively changed/unchanged files from edition bulk chain.

Bonus if the comparison return only the changed fields so the edition bulk chain can not edit of all the fields. (Not sure if this will really work, the bulk chain may not be smart enough to select only some fields).

• Add relevant columns in admin index;
• Add useful filters in admin index;
• Improve searched fields;
• Look to improve add and changes form, especially for MediaFile;