Recordings no longer playing properly/"! The channel is scrambled or not available"

If you can wait, give other people a chance to read that and double check it.
Ok, I'll wait say until 8.00 tonight.

Yesterday, after updating to 2.14 I removed sysmon based on some fuzzy memory of sthing I read before. After removal I checked the recordings and they were still stuttering. However after about half to one hour I noticed that some recordings which were stuttering, stopped doing so and played OK. It could have been after I'd done the HDD test you advised yesterday but I'm not exactly sure. Now some recordings (stuttered before) play well but sthing recorded yesterday at 8pm does not seem right. Cursor stays at 36min out of a total time of 39min, but it keeps playing/interrupting for longer than the 3 remaining minutes. The program should have lasted 2 hrs.
 
I removed sysmon based on some fuzzy memory of sthing I read before.

Sysmon has a tentatively-observed effect of magnifying anything that's duff. Certainly in my case playback went from HiDef almost unwatchable (in the recording) to perfect coincident with removing the sysmon package. There is probably something failing somewhere, but I am putting off the recovery operation.
 
To attempt to fix this, you can type the following from the command line:

Code:
humax# dd if=/dev/zero of=/dev/sda bs=512 seek=410253531 count=1

If you can wait, give other people a chance to read that and double check it.
I run it and I got this:
/bin/sh: #: not found
 
When you get the telnet prompt, just type the command starting with the dd. The humax# bit is the default telnet prompt, shown for context.
 
I thought that's what I did. Anyway tried again got this
Code:
BusyBox v1.20.2 (2013-01-02 19:13:09 GMT) multi-call binary.
 
Usage: dd [if=FILE] [of=FILE] [ibs=N] [obs=N] [bs=N] [count=N] [skip=N]
        [seek=N] [conv=notrunc|noerror|sync|fsync]
 
Copy a file with converting and formatting
 
        if=FILE        Read from FILE instead of stdin
        of=FILE        Write to FILE instead of stdout
        bs=N            Read and write N bytes at a time
        ibs=N          Read N bytes at a time
        obs=N          Write N bytes at a time
        count=N        Copy only N input blocks
        skip=N          Skip N input blocks
        seek=N          Skip N output blocks
        conv=notrunc    Don't truncate output file
        conv=noerror    Continue after read errors
        conv=sync      Pad blocks with zeros
        conv=fsync      Physically write data out before finishing
 
Numbers may be suffixed by c (x1), w (x2), b (x512), kD (x1000), k (x1024),
MD (x1000000), M (x1048576), GD (x1000000000) or G (x1073741824)
 
Can you cut and paste the command that you typed? Is it possible you added spaces around the equals signs?
 
This is the whole line
humax# dd if=/dev/zero of=/dev/sda bs=512 seek=410253531 count1

I only typed from dd
 
Damn. I would've sworn on it being identical.
I got this
dd: writing '/dev/sda': Input/output error
1+0 records in
0+0 records out
0 bytes (0B) copied, 7.852000 seconds, 0B/s
 
Well, that didn't work. We can do it the hard way by calculating partition offsets etc. or you could try the fix-disk in the CFW 2.15 beta that should be able to do all that for you.. want to give it a go?
 
I've had a quick read up and the syntax looks OK. All I can offer are the obvious: is there a /dev/sda and is it writable?
 
I think af123 was asking users who are familiar with the dd command as they are more likely to be able to see a potential error :)
 
Indeed, but nobody answered. In any case, sometimes one can be blind to one's own typos ("baring"?).
 
Ok, let's try to fix this another way.

Install the hdparm package and the confirm that the disk sector is definitely faulty by trying to read it:

Code:
humax# /mod/sbin/hdparm --read-sector 410253531 /dev/sda

If it is faulty, you should get an I/O error.

Try reading the next one up to confirm that it works ok.

Code:
humax# /mod/sbin/hdparm --read-sector 410253532 /dev/sda
 
Back
Top