new files not refreshed - due to DVR lock?

I don't really know how to start it any other way, I just use the auto-start up tool in Linux Mint KDE to start it as the PC boots up.

Update, i just had a nosey around in the Linux Mint start up tool and found where I can start it as another user, so I set it to lee.
Will reboot and have a look what happens.

So far I am not seeing any difference, its still seemingly randomly deciding if it wants to import files or not.
I also noticed it stopped updating the log files late last night. I just deleted them (saved to another folder actually) but don't see any new ones created.

[EDIT] After a reboot it started creating log files again.

[Brett]

You also have

F:\dvr\BBC News
F:\dvr\PBS News Hour

Can you remove those as they will be searched automatically by adding F:\dvr

Sorry, I had those in the list but did not have any media enabled for those directories.

For the attached logs I've tried to simplify everything.

1 folder is defined (D:/dvr) on an internal drive. It is empty to start with.

stopped service, cleaned logs, started service

12:24 - start recording "The Insider"
12:26 - stop recording
12:28 - add a copy of the recorded video to the directory

The copy appears in my "Last Added" list. The original file that was recorded by the DVR does not appear in the list.

Thanks for helping.
Brett

I was looking further into this over the weekend and found the cause of the problem (on Linux).

I am using Linux Mint 17.1 KDE 64bit and noticed that it's search function was not working, it was giving a 'protocol error' when trying to use it.
I Googled for this and found that the search system 'baloo' was missing and needed to be installed, so I followed the instructions for that and installed it.
Search now started working, though as it was still doing it's initial indexing was a bit slow to find things.

I decided then to see if Serviio had improved, on the off-chance the problems were related. I found no change with Serviio, files were still not found, so I switched off POLLER and restarted the PC and did some further testing. Any files that I now move around, add, delete or rename that are monitored by Serviio are now found correctly and almost immediately.

The only drawback at the moment is that this baloo search is using quite a lot of CPU power - I am hoping that this is still it's initial indexing and will settle down once done, but I will have to keep a check on that. I have been Googling about that and found that it is indeed quite buggy and many people reported it locks the CPU at 100% use so I suspect this may be the reason it was not installed with my Linux distro in the first place.
Further Googling revealed that sometimes it gets stuck on a file and locks at a 100% CPU use, but the following can help with that:

This is a new issue that has cropped up. It seems we are using newer features of Xapian which are causing the database to get corrupted.

The only way to fix it now is to run -
$ balooctl disable
$ balooctl enable

This will reset the database and restart it.

Taken from https://forum.kde.org/viewtopic.php?f=154&t=120468

I tried it and CPU usage did go back down though is still higher than it should be as it looks like baloo has not finished indexing yet.

Anyway, I hope this helps someone. Thanks for all the help with this here!

[zip]

For the attached logs I've tried to simplify everything.

1 folder is defined (D:/dvr) on an internal drive. It is empty to start with.

stopped service, cleaned logs, started service

12:24 - start recording "The Insider"
12:26 - stop recording
12:28 - add a copy of the recorded video to the directory

Thanks, I think this should now be fixed for 1.5.2. I'll add you to the betatester group to give the new beta a try when it's out - feedback will be welcome.

[Brett]

Thanks, I think this should now be fixed for 1.5.2. I'll add you to the betatester group to give the new beta a try when it's out - feedback will be welcome.

Awesome!!!
Thanks,
Brett

[madprogrammer]

Hi,

I also have problems with automatic update. After some time new files copied into the directory being watched by Serviio don't appear in the library, and are not detected. Manually forcing an update makes the new files appear. Also, I get the "[LibraryDeltaScanner] Added repository '/media/collection' to delta scanner (POLLER)" message even though my system has inotify support, and tools like inotifywatch work.

Linux 3.17.7
Serviio 1.5.1

Want to try the beta version.

Serviio has been behaving just perfect for me since my last post in this thread and then out of the blue no longer showed up on my Sony Bluray player.
I checked the PC and the Serviio Console had closed.
I tried to restart Serviio and had the following error:

lee@Badbunny-Linux:~/.Serviio/bin > ./serviio.sh -start
log4j:ERROR setFile(null,true) call failed.
java.io.FileNotFoundException: /home/lee/.Serviio/log/serviio.log (Permission denied)
at java.io.FileOutputStream.open0(Native Method)
at java.io.FileOutputStream.open(FileOutputStream.java:270)
at java.io.FileOutputStream.<init>(FileOutputStream.java:213)
at java.io.FileOutputStream.<init>(FileOutputStream.java:133)
at org.apache.log4j.FileAppender.setFile(FileAppender.java:294)
at org.apache.log4j.RollingFileAppender.setFile(RollingFileAppender.java:207)
at org.apache.log4j.FileAppender.activateOptions(FileAppender.java:165)
at org.apache.log4j.config.PropertySetter.activate(PropertySetter.java:307)
at org.apache.log4j.xml.DOMConfigurator.parseAppender(DOMConfigurator.java:295)
at org.apache.log4j.xml.DOMConfigurator.findAppenderByName(DOMConfigurator.java:176)
at org.apache.log4j.xml.DOMConfigurator.findAppenderByReference(DOMConfigurator.java:191)
at org.apache.log4j.xml.DOMConfigurator.parseChildrenOfLoggerElement(DOMConfigurator.java:523)
at org.apache.log4j.xml.DOMConfigurator.parseRoot(DOMConfigurator.java:492)
at org.apache.log4j.xml.DOMConfigurator.parse(DOMConfigurator.java:1001)
at org.apache.log4j.xml.DOMConfigurator.doConfigure(DOMConfigurator.java:867)
at org.apache.log4j.xml.DOMConfigurator.doConfigure(DOMConfigurator.java:773)
at org.apache.log4j.helpers.OptionConverter.selectAndConfigure(OptionConverter.java:483)
at org.apache.log4j.LogManager.<clinit>(LogManager.java:127)
at org.slf4j.impl.Log4jLoggerFactory.getLogger(Log4jLoggerFactory.java:66)
at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:277)
at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:288)
at org.serviio.MediaServer.<clinit>(MediaServer.java:77)
Thu Apr 09 19:49:02 CEST 2015 Thread[main,5,main] java.io.FileNotFoundException: /home/lee/.Serviio/library/../log/derby.log (Permission denied)
----------------------------------------------------------------
Thu Apr 09 19:49:02 CEST 2015:
Booting Derby (version The Apache Software Foundation - Apache Derby - 10.11.1.1 - (1616546)) instance a816c00e-014c-9f4c-a527-ffffb552a19b
on database directory /home/lee/.Serviio/library/db in READ ONLY mode with class loader sun.misc.Launcher$AppClassLoader@28d93b30.
Loaded from file:/home/lee/.Serviio/lib/derby.jar.
java.vendor=Oracle Corporation
java.runtime.version=1.8.0_40-b25
user.dir=/home/lee/.Serviio/bin
os.name=Linux
os.arch=amd64
os.version=3.16.0-33-generic
derby.system.home=/home/lee/.Serviio/library
derby.stream.error.file=../log/derby.log
Database Class Loader started - derby.database.classpath=''

Long story short, after a lot of messing about I deleted the entire Serviio folder and started again using v1.5.1.
This made no difference so I tried v1.5.2, but same kind of problem.
More messing about, basically doing the same things again and now Serviio runs, however the Delta scanner no longer works, either with v1.5.1 or v1.5.2 so i switched to the POLLER scanner which works, though is not as fast as noticing new or changed media. I set it to a 5 minute interval, any lower and I wonder if that is going to make my PC locked in a permanent scan for new media?

I love Serviio, it is so simple to install and use on this PC when I boot into Windows, but in Linux I am almost spending more time trying to keep it running than i do actually using it what it was intended for.

[zip]

It all looks like access rights. The error above means that the user running the app doesn't have write access rights to the installation folder.

It all looks like access rights. The error above means that the user running the app doesn't have write access rights to the installation folder.

That was my thinking too, but when i checked the folder everything looked correct as far as I could see, and I had not changed anything.
Deleting the folder and creating a new one with a fresh installation of Serviio seemed to correct it, though the Delta scanner still remains oddly broken for some reason.

Linux is not as stable as people like to believe I think, at least not from my experiences of it in the past month.