Closed A380Coding closed 3 years ago
Geektoolkit
commented
3 years ago Thankyou for this. After reading it and looking at what you're saying, this makes sense why I'm not seeing it as much, and why the code's busted. I knew I had to rewrite that random logic, but hadn't gotten there. I'll work to get this fix into the next build, and REALLY appreciate not only the investigation but the fix!
A380Coding
commented
3 years ago No problem. Please have a quick test as I did this out of my head. Can the log be deactivated? Would like to have the option for it since it might wear down the SD card? I think i saw in the log that the reshuffling happens not only at startup and listing a thousand files each time generates big log files in the end.
And if the date/time text on the image could have some background shape or outline would be good for readability in case the image has larger white parts e.g. snow. But probably I should post this somewhere else to not mix up topics.
Geektoolkit
commented
3 years ago Yeah, please file two seperate for the logger control as well as readability of the text. I'm thinking even a 20% opacity black rectangle or something may do it, and can even have some settings for opacity and such.
I'll get this into the next build for testing. I'm fixing some bad bugs I'm hitting right now.
Geektoolkit
commented
3 years ago 2.18 has the new algo put into it. Please feel free to give that a spin and let me know if that's any better. I am going to see what I can do to push the logs to the webUI to make debugging that much easier.
A380Coding
commented
3 years ago Finally had some time and updated to 2.18. Shuffling works for me as expected, files at the end of the log are also well shuffled. Enabling/Disabling the log via the webGUI would be appreciated.
But I'm hitting at lot of these in the log file: omxplayer.bin: Process not found
Is it "safe" to start DynoFrame via cronjobs? With my current setting based on FBI I start and stop FBI and the screen multiple times a day leaving the raspberry turned on.
Geektoolkit
commented
3 years ago The omxbinplayer is a known issue, it can be ignored for now. Basically I try to kill it often because leaving the process running can be disasterous, but since the code is so aggressive if it doesn't find it it complains. I need to just quiet that warning.
The next major feature is actually to allow for the logs to be pumped to the web gui, I can add an enable/disable also. I have to do that to make debugging easier and fix some issues (my frames are 'stalling' when doing multi frame work currently).
As far as starting/stopping via a cronjob, I'm not sure. does it run as user? I think I tried that and it gave me issues because it has a user interface, but I honestly don't recall at this point. I ended up in a wierd spot of 'well this runs it as root (which is bad, please don't do that...it crashes)' or I hit issues where the method didn't support pushing a UI. There's nothing in the code that should stop it if the method you want to launch supports running with a User interface as 'user'
Geektoolkit
commented
3 years ago omxplayer errors will be fixed in the next release. logging enable/disable is being added for the webgui based on your feedback Also remote viewing (from the webpage) Pushing a build up now (2.19) and will let it get into testing.
Geektoolkit
commented
3 years ago 2.19 is published, closing this, please reopen if you see issues still. I'll look at the other two bugs/issues.
I loaded several folders with several thousand pictures into a folder. The shuffle option is activated. I found the random function not working quite well. Taking a look at the log file and the playlist dump, I can see that the file names are quite random at the beginning, but the more I get to the end of the playlist dump, the less random the list is. I checked in the code and found this:
public static IList<T> Shuffle<T>(this IList<T> list, Random rnd) { for (var i = list.Count; i > 0; i--) list.Swap(0, rnd.Next(0, i)); return list; }I think this reflects the problem. The loop goes from list.Count down to 0. And the list.Swap always takes image 0 and exchanges it with a random image between 0 and i. As i counts down from max to 0 the end of the list will be less shuffled compared to the beginning of the list. That matches to what I see in the log as well. It should be something like (change in ): `public static IList Shuffle(this IList list, Random rnd)
{
for (var i = list.Count; i > 0; i--)
list.Swap( i, rnd.Next(0, list.Count -1**));
return list;
}`