usb support for read only is something i can consider.
usb support for writing received files into isn’t viable - I already explained that. its not a question of “bringing it back”. if it was fixable, I’d fix it now instead of removing it. But its not fixable (open to ideas of course).
So I am not sure how I could bring it back. As explained - its nothing to do with “more polished”. Its not a bug in the system.
Good to hear! Thanks for the report!
As far as larger storage solution is concerned, we have another option in the works.
Read only would be fine. Being able to add our own files was my concern. I haven’t been experiencing the same issues that the other people here have had so there isn’t much I can do to help find a solution. I look forward to your solution for larger storage.
On further consideration, here is what I have tentatively decided to do (this is independent of the larger storage options that will appear later with our fully integrated receiver). Consider this a “request for comments”.
usb stick for writing during normal device operation is not an option. it breaks too often and leads to an essentially non-functional device. Also - the “merged” fs view - combining both the internal storage and external storage into a single virtual whole - was a constant source of trouble. So thats gone.
My original idea (as I had proposed above), was to switch usb device to just archival usage: when you plug in a usb stick, if it is cleanly mountable, the system will sync all the files from onboard storage to the usb stick, and then unmount the stick.
After what @demandzm said, it seems there is value in merely having the usb as a read only option. It won’t have new files written to it, but the files already on the usb stick can be served thru the UI. This is a viable option.
So, what I propose to do is a combination of (2) and (3) above:
4a. when a usb stick is inserted, if it is mountable as write device cleanly, files from onboard storage will be synced to it. the device will then be unmounted.
4b. then the device will be remounted as “read only”, and the UI will see a merged view of the usb stick and onboard storage.
4c. New files as received will not be written to usb stick (so its synced state will be as it was when it was initially plugged in). If you want to update the archive on the stick, unplug and replug it.
Does that serve your use scenarios? any issues you see with the option?
I like those ideas. Given that scenario, I can put my 64 GB stick back in with the 32 GB Rachel files and anything else I might want in the box. As to inserting it for clean backups - - then un mounting it presents a problem for me with a buttoned up Lantern - - remember the 10 screws
You could work something out with read only, and some other manual system for doing the backup storage without having to remove/insert the stick.
My thinking about what to save - - just the Wikipedia files and other reference matterial. No need to save all the Weather, APRS, and News. Ken
I believe the only value in archival would be if you want to be able to view those archival files on a stand alone device (the Lantern) without external computer support. Ken
Running my fresh flashed Librarian since 3 days now and still recieve files in opaks folder. It running without an usb drive and the files in opaks folder doesn’t extract. Is there a way to do this manualy?
And i got BBC News in the root directory. how can i delete this without getting the message of “File not found”?
can you show me a screenshot of the files in opaks?
Librarian takes some time to “forget” files. If you ssh in and run “oncontentchange” on the command line, Librarian should refresh its index in a few minutes.
yes. the opaks thing is fine: those two specific files are actually zero-length that got sent down by mistake. the system sees it as an error and refuses to process them. Just go ahead and delete those.
oncontentchange: yes, that means you should hopefully not see the “file not found” anymore.
Though Librarian is very buggy and I can’t guarantee that will happen.