Arch Linux User Repository

I had trouble during linking on armv8 due to libdl.so not being linked. There's probably a more elegant way to solve this, but I did it in the PKGBUILD with sed -i 's/${CMAKE_CXX_FLAGS}/${CMAKE_CXX_FLAGS} -ldl/' CMakeLists.txt. Otherwise, gerbera works great on armv8 and you could add this to the supported architectures. :)

I added a non-conflicting package libupnp1.12 at https://aur.archlinux.org/packages/libupnp1.12/ based on the libupnp18 PKGBUILD. You can just add export PKG_CONFIG_PATH="/usr/lib/libupnp-1.12/pkgconfig/:${PKG_CONFIG_PATH}" before the cmake call to use it if you want to change the dependency.

You can uninstall libupnp18 by ignoring dependencies (pacman -Rdd libupnp18) and then applying the update. As this removes a dependency stop Gerbera first!

I noticed the issue with libupnp when updating via trizen, it asks me if I want to replace libupnp18 with libupnp-git but if I say "Yes", then it fails because gerbera needs libupnp18. How do I overcome this? I thought of uninstalling gerbera then reinstalling it, but I fear losing my settings.

Upgrade to 1.5.0: * libupnp18 needs to be replaced with libupnp-git * some dependencies added and some dropped * this is a major change - reindex might be needed

@sulaweyo: Ups. You're absolutely right, my fault. Sorry.

@preinkemeier did you test it? According to the pull request this flag is on by default https://github.com/gerbera/gerbera/pull/540/files

Sorry, it doesn't work that way. You have to tell cmake to enable libmatroska. That means you have to replace the following line in your PKGBUILD:

cmake -DCMAKE_INSTALL_PREFIX=/usr -DWITH_AVCODEC=1 -DWITH_FFMPEGTHUMBNAILER=1 .

with this one

cmake -DCMAKE_INSTALL_PREFIX=/usr -DWITH_AVCODEC=1 -DWITH_FFMPEGTHUMBNAILER=1 -DWITH_MATROSKA=1 .

Otherwise nothing will change.

The problem seems to be that the db layout has changed but no migration was done. It works for existing data but new items cannot be added or updated. An easy workaround is to drop the sqlite db and just reindex (shutdown gerbera, remove db file, restart gerbera and re-add the directories to index) but i will dig deeper if there is a way to trigger the db migration cleanly.

Looks like i found the culprit. In one db upgrade there is a change to a table that adds a foreign key to an existing table. This seems to work on all DBs except on sqlite according to what i found so far. When a new db is created the foreign key is there already so it works as there is no change to the structure of an existing table. Need to play around with that a bit but i guess i'll upstream a fix. Until then please just do a reindex please.

gerbera is throwing 101 iterations of this error message (with variations, e.g. 454503,4, and 6 although duplicated, there are others indicated): 2019-11-23 15:20:32 ERROR: Exception caught: SQLITE3: (1 : 1) no such table: main.cds_object Query:DELETE FROM "mt_cds_object" WHERE "id" IN (454503,454504,454506) error: no such table: main.cds_object Exception raised in [src/storage/sqlite3/sqlite3_storage.cc:392] waitForTask(): SQLITE3: (1 : 1) no such table: main.cds_object Query:DELETE FROM "mt_cds_object" WHERE "id" IN (454503,454504,454506) error: no such table: main.cds_object, but otherwise is working. Started after 1.3.2-2 version. Sqlite3 dump of gerbera.db doesn't show anything different from other strings that aren't erring.

EDIT: @sulaweyo, thanks for the workaround, it works for now :)