Timeline for Temporary blocking all network access for a limited time while a CPU sensitive task is running
Current License: CC BY-SA 3.0
16 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 7, 2016 at 9:03 | vote | accept | 576i | ||
| Sep 23, 2016 at 22:15 | comment | added | 576i | @ppumkin - it's a headless server but well within reach of the person that wants his recordings bit error free... | |
| Sep 23, 2016 at 13:21 | comment | added | Piotr Kula | If it's in a remote place... who is gonna unplug and plug it back in? Just saying :) | |
| Sep 23, 2016 at 8:41 | comment | added | 576i | @ppumkin - if the device doesn't come back, unplug, plug back in... just like any headless raspberry that becomes unresponsive. .Reg other comments: The recording is done by a software (tvheadend) that behaves badly when too much load happens - changing the software behavior is out of my reach. The goal here of an undisturbed recording has priority over everything else, including SSH access, so dropping network while a recording runs to prevent accidental access to the pi by anyone is a solution... | |
| S Sep 22, 2016 at 18:42 | history | suggested | psmears | CC BY-SA 3.0 |
Improve grammar and wording
|
| Sep 22, 2016 at 17:56 | history | tweeted | twitter.com/StackRaspi/status/779016633939533824 | ||
| Sep 22, 2016 at 17:48 | comment | added | Piotr Kula | Why not just block users from accessing the device for that time period. Dont take down ethernet.. what if it doesnt come back up | |
| Sep 22, 2016 at 17:29 | answer | added | Zak | timeline score: -1 | |
| Sep 22, 2016 at 16:25 | review | Suggested edits | |||
| S Sep 22, 2016 at 18:42 | |||||
| Sep 22, 2016 at 14:36 | comment | added | Mast | You really don't want to do this. What if you try to run this over SSH? | |
| Sep 22, 2016 at 12:13 | answer | added | Simon Richter | timeline score: 1 | |
| Sep 22, 2016 at 11:37 | comment | added | Benjwgarner | This is a rather "hacky" solution that seems to attempt to avoid another problem that could potentially cause other issues that have not yet been identified. As much as I hate to be that over-opinionated StackExchange jerk who insists that your question should not be answered because you're asking the wrong question, this does not seem like the best solution. It's like the joke about the patient who tells a doctor, "It hurts when I do this", and the doctor admonishes the patient not to "do that". The solution to having problems with incoming network connections during recording shouldn't just | |
| Sep 22, 2016 at 10:46 | answer | added | Dmitry Grigoryev | timeline score: 4 | |
| Sep 22, 2016 at 10:14 | comment | added | MSalters | Wouldn't it be a lot easier to just renice the recording process so it gets all the CPU it needs? | |
| Sep 22, 2016 at 7:25 | answer | added | Steve Robillard | timeline score: 7 | |
| Sep 22, 2016 at 6:39 | history | asked | 576i | CC BY-SA 3.0 |