piCorePlayer Documentation

[Grumpy Bob]

Added "USBImager" under "Burn piCorePlayer onto a SD card" How-to.

Help required: Who uses MACs? We require a few words and imagines on "How-to Burn piCorePlayer onto a SD card for Mac OSX".

Well I use ApplePiBaker, there is copious information and guidance at the website.
I find it rather good to take periodic backups of my Pi SD cards, so I do use it quite frequently.

The ApplePiBaker app has three panes: Select a disk; then panels for Backup (you specify the filename, format and location for the backup file) and Restore (you select the image you're restoring). As with the Windows guidance, I'm always careful to make sure I'd performing these actions on the SD card and not the main drive on my MacBook.

I have a MacBook with only USB-C ports, so I bought a plugin device for burning and reading SD and microSD cards that connects through USB-C.

Robert

[Greg Erskine]

Added "USBImager" under "Burn piCorePlayer onto a SD card" How-to.

Help required: Who uses MACs? We require a few words and imagines on "How-to Burn piCorePlayer onto a SD card for Mac OSX".

[prabbit]

Looking good!

Good to see this repo!

I know that the pCP team will be doing a lot of the primary writing and heavy lifting of the documentation. If there's anything the community can do to help, I would encourage the team create items in the issues list, perhaps with a tag of "help wanted."

[Greg Erskine]

The piCorePlayer Documentation GitLab repository is now public.

piCorePlayer Documentation Source - GitLab

I have not documented the GitLab process yet. I assume most of you know more about git than I do.

[jeroen2]

By default, I don't think LMS uses a separate partition for cache and preferences. The cache and preferences are written directly to a persistent location on the SD card (boot device). You can move them though.

Ah, I see. Only just learned about the difference between mmcblk0p2 and mmcblk0p1 from your latest FAQ. Thanks.

[Greg Erskine]

Added "Can't see the boot partition" and "Can't see the root partition" FAQs.

[Greg Erskine]

hi jeroen2,

Thanks for the feedback.

Yeah, we need a little documentation regarding the LMS cache and preferences. I am not sure where it goes though?

By default, I don't think LMS uses a separate partition for cache and preferences. The cache and preferences are written directly to a persistent location on the SD card (boot device). You can move them though.

regards
Greg

[jeroen2]

Added "My changes disappeared" FAQ and related "piCorePlayer backup" Information.

That's very useful, thanks.

But maybe it would be good to add a note about LMS, because that had confused me a bit at first. If I understand correctly it would be some like this?
"NOTE: Logitech Media Server (LMS) is a server database application and needs to write to disk frequently. If you run PcP as a player/Server LMS gets a separate partition on the SD card to write cache data, a database index and settings files. These do not require the use of PiCorePlayer backup to remain in tact after a reboot. To preserve the SD it's recommended to switch off the Pi using the shutdown command or the button on the PcP homepage before pulling the power."

[Greg Erskine]

Added "My changes disappeared" FAQ and related "piCorePlayer backup" Information.

[nowhinjing]

You are welcome ...

We added "Adding a 3.5" display" project to the piCorePlayer Documentation.


https://docs.picoreplayer.org/projects/add-a-display/

... glad to be of service, sir !

[Greg Erskine]

Add a display

We added "Adding a 3.5" display" project to the piCorePlayer Documentation.

piCoreplayer by default supports the official Raspberry Pi 7" Touchscreen Display. However, there are dozens of screens available for Raspberry Pi. These instructions are for a generic 3.5inch RPi Display but may also give clues how to support other screens. A big thanks to nowhinjing for his Waveshare 4.1 TFT + piCorePlayer + Jivelite tutorial which was used as a starting point.

https://docs.picoreplayer.org/projects/add-a-display/

[Greg Erskine]

Submitting content

We just added the "publishing" section to the piCorePlayer Documentation. Most of this is so we don't forget how to publish the documentation but a couple of documents are relevant to people wanting to submit content.

https://docs.picoreplayer.org/publishing/

[Greg Erskine]

piCorePlayer Help is dead, long live piCorePlayer Documentation!!

https://docs.picoreplayer.org/

Please report any dead links to piCorePlayer Help. We are putting in page redirects where possible.

Next step is to document the documentation process then make the piCorePlayer Documentation git repository public.

[Greg Erskine]

Hi Jim,

Thanks for your input.

The new publishing process makes it a lot easier write and update documentation, so that is a major obstacle removed.

I agree with what you are saying but as a general rule, but documentation is never going to be just right because the audience is at different levels of understanding.

Personally I like something like this:

Click [Resize FS] to resize the file system--see "Resizing file system".

An clear action with a brief concise description and a link to detailed information.

So:

• An expert would read: Click [Resize FS]
• A normal user would read: Click [Resize FS] to resize the file system
• While a novice would read: Click [Resize FS] to resize the file system--see "Resizing file system".

regards
Greg

[Redrum]

Greg (and others);

I took a quick look through, this is wonderful, thank you for the effort to date. I do have a thought though...

When I setup my first picore player, I followed the "how to" step by step and was successful, but often didn't understand "why", what the purpose of the step was. For example "resize the file system", "Move Cache and prefs", etc. After a lot of time in these forums, addressing issues, reading the efforts of others, I slowly understood much of what those steps mean, what they are actually doing. I got to understand the system. Of course following the how tos I got up and operational quick, I just didn't fully understand what I had just built, and therefore what I could/should change.

For example, I get frequent power failures with a picore (server only) and attached USB HDD. The power interruptions caused the HDD mount to get lost. I had to remount the HDD and sometimes rebuild LMS. All this because I moved Cache and Prefs to the HDD. Now, I keep them on the SD, in fact, I created a third partition on the SD for cache and prefs (per a recommendation from Paul). I never understood what the step meant, or that it was not required to have an operational system. I now (through the forums) know.

So, if I can make a suggestion (I would be willing to help if I could), maybe think to add some "what it is you are doing and why" to the steps. EG:

1) Why do I have to resize the file system? Are there factors that would make a user want to make it even bigger?
2) When I am moving cache and prefs, what does this mean? Even adding, "this step is recommended but optional because..."

Not trying to create extra work, just thought I would give you a perspective from the experience I went through as a LMS vet, but a Picore noob (at the time). I might have been more mystified if I was a full noob


Jim