Dmedia 13.05

Milestone information

Project:
Dmedia
Series:
trunk
Version:
13.05
Released:
2013-05-28  
Registrant:
Jason Gerard DeRose
Release registered:
2013-05-28
Active:
No. Drivers cannot target bugs and blueprints to this milestone.  

Download RDF metadata

Activities

Assigned to you:
No blueprints or bugs assigned to you.
Assignees:
5 Jason Gerard DeRose
Blueprints:
No blueprints are targeted to this milestone.
Bugs:
5 Fix Released

Download files for this release

After you've downloaded a file, you can verify its authenticity using its MD5 sum or signature. (How do I verify a download?)

File Description Downloads
download icon dmedia-13.05.0.tar.gz (md5, sig) tarball 10
last downloaded 65 weeks ago
Total downloads: 10

Release notes 

Note: Dmedia has NOT earned its "production ready" wings yet, so please treat this release with the usual caution. Test Dmedia, give us feedback, but don't trust your data to it... yet.

In Dmedia 13.05 we've switched over to the final, version 1 hashing protocol. Because of the change from Base32 to Dbase32 encoding, we cannot support V0 alongside V1. To upgrade your existing V0 library to V1, open a terminal and run:

  novacut-v0-v1-upgrade

Which will upgrade both your Novacut databases and Dmedia. Optionally, if you only have Dmedia installed, run this instead:

  dmedia-v0-v1-uprgade

Please see this video tutorial on doing the upgrade:

  http://www.youtube.com/watch?v=NOyEIab0E-U

Changes include:

* Switch to Dbase32 encoding for random IDs and for user/machine IDs, as FileStore now uses the V1 hashing protocol by default

* Because of the schema version bump, the main Dmedia database is now "dmedia-1", and the project databases are "dmedia-1-<PROJECT_ID>"

* Ported to the new FileStore.create() explicit creation API; got rid of hacky util.init_filestore(), util.get_filestore() functions

* Greatly improved how background tasks are scheduled: now at most one drive (FileStore) will be verified at a time, but a scan/relink task can also be running at the same time, without waiting for the verification to finish; now the vigilance task only does copy-increases, is always running

* Turned the copy-decreasing behaviour back on: when there is less than 16 GiB free on a drive, and assuming it's safe to do so, files are now automatically reclaimed; as Dmedia will increase copies up to the point where only 8 GiB of space will be available *after* the new copy is created, there is an overlap between the copy increasing and decreasing thresholds that creates a natural "flow" when there are files with low durability, or when the user requests a file not available locally

* The dmedia/log docs that were saved into "dmedia-0" have been slightly tweaked in V1 and are now saved into "log-1", which will be used as a unified event logging DB for all Dmedia using apps; plus, the new dmedia/log docs now use the new `dbase32.log_id()` function, which produces so called "monotonic" IDs that will sort in chronological order with a 1 second granularity

* Verification is now driven by 2 view functions, "file/mtime-store" and "file/verified-store", so that there is some grace period between when a new copy is created and when it will be verified; this prevents the verification task from nipping at the heals of the copy increasing task, which could cause a lot of IO thrashing and make a system unreasonably slow

* MetaStore.scan() is now faster and more memory efficient on FileStore with a large number of files (say over 10,000)

* Added new dmedia/migration.py module with V0=>V1 migration functionality; added unit tests for the same

* Added Core.add_peer(), Core.remove_peer() methods which make Core responsible for both tracking currently connected FileStore, and currently visible peers; importantly, Core now restarts the vigilance loop whenever the connected FileStore *or* the visible peers change; as a result, the copy increasing task (vigilance) can immediately respond to a new peer from which needed files might be available

* Added Dmedia.SkipInternal() DBus method which (as a stop gap) you can use to tell Dmedia not to store any files in ~/.local/share/dmedia/.dmedia, which you can use with dmedia-cli like this:

  dmedia-cli SkipInternal true

(You'll have to restart Dmedia for the change to take effect.)

* Service.start_core() now does less work, which will hopefully lessen problems with DBus timeouts on slow systems (the real issue here is CouchDB can take a long time to start)

* Experimental `dmedia-format` script now derives the ext4 UUID from the Dmedia store_id, so there is a stable relationship between the two

* The `dmedia` package now depends on `ntp`, as a workaround for the SSL certificate not being valid immediately after peering because of clock differences between the two systems; this probably isn't the correct long-term solution, but at least it ensures the peering will be reliable, will make a good first impression

Changelog 

This release does not have a changelog.

0 blueprints and 5 bugs targeted

Bug report Importance Assignee Status
1069582 #1069582 dmedia-extract crashed with TypeError in function(): argument query: Expected Gst.Query, but got gi.repository.Gst.Query 2 Critical Jason Gerard DeRose  10 Fix Released
1131471 #1131471 Dmedia stopped during import 3 High Jason Gerard DeRose  10 Fix Released
1174035 #1174035 Switch to V1 protocol, dmeida-1 3 High Jason Gerard DeRose  10 Fix Released
1176427 #1176427 Add tool to migrate V0 Dmedia library to V1 3 High Jason Gerard DeRose  10 Fix Released
1180163 #1180163 Port to new FileStore.create() API 3 High Jason Gerard DeRose  10 Fix Released
This milestone contains Public information
Everyone can see this information.