Messages

1st of all, love the imagination with your username.

After posting the information I looked at the 32GB card with GParted and saw that lpa was the only flag. So that left me scratching my head. That said, I left the boot flag and it continues to work without any lag or distortion. I have no issues whatsoever. When I have more time all dd the 64 gig card and try to figure out why this is working so nicely, unless you already know.

Cheers
Chris.

Good morning.

Thank you for the advice. I replaced the 32GB card with a 64GB card and it now works fine. I had also read that everyone has been having issues with cards >32GB. I'm not sure if I solved this issue but the method I used worked flawlessly. See my post here. https://www.2box-forum.com/index.php?msg=32659

Again, thanks for the help.

Cheers
Chris

So it works!

I would be interested to see if it can be repeated by anyone else. Look forward to reading more.

Cheers
Chris

[Media]

Here are my 2cents and preliminary results. (I will elaborate in a future post). I'm a Linux guy and I take a systematic approach to problem solving technology issues. Plus I have a dislike for anything Microsoft, especially where key events happen behind a GUI. So I've taken a foundational approach to troubleshooting this issue. For an OS to initialize and start up, the media, or in this case the SD card, needs to be able to tell the BIOS I have what you need to boot correctly. If not the boot procedure will fail and you will somehow be told the OS did not start and for you to "pound sand". Therefore, it makes perfect sense that simply copying files from the 32GB SD to the 64GB card won't work, even if formatted to fat32. In the original 32GB card, although I haven't checked this, I would hazard a guess that the boot flag is set. This would explain why imaging the 64GB SD with the 32GB image works... because the boot flag was previously set.

With this in mind, this is what I did.

Media: SanDisk Extreme PRO SDXC UHS-I. 64GB, 200MB/s

Procedure: Formatted the entire 64GB partition to fat32, set the Boot bit, and renamed volume to 2Box.

Created filesystem fat32 on partition '/dev/mmcblk0p1'

1st: Delete file system on '/dev/mmcblk0p1'
Command: wipefs --all /dev/mmcblk0p1
2nd:: Create file system 'fat32' on partition '/dev/mmcblk0p1'
Command: mkfs.fat -F32 -I -v /dev/mmcblk0p1
Command: sfdisk --part-type /dev/mmcblk0 1 c
3rd:: Check file system on partition '/dev/mmcblk0p1'
Command: fsck.fat -a -w -v /dev/mmcblk0p1

4th:: Set flags for partition '/dev/mmcblk0p1' to boot;
Command: sfdisk --activate /dev/mmcblk0 1

5th:: Set the file system label on partition '/dev/mmcblk0p1' to 2Box;
Command: fatlabel /dev/mmcblk0p1 2BOX

6th: Extracted the contents of DrumIt5_MK2_CC_Second.zip to the new 64GB 2Box SD card. The ...Second.zip file contains the OS, DrumItOS1.36.3.bin.

7th: Inserted the 64GB card with ONLY the contents of DrumIt5_MK2_CC_Second.zip, hit the power button and.... SUCCESS.

8th: Came back to my laptop, wrote this message while extracting the contents of DrumIt5_MK2_CC_First.zip in the new 2Box 64GB SD card.

9th: Posted this message and I am now on my way to see if everything still works... I'll get back to you soon.

Cheers
Chris

[HW Config]

Hi.

HW Config: Serial number is 000148, Boot is 1.37, OS 1.36.3, all cabling replaced yesterday.

Background: I just bought a used 2box MKll. The only history I have on the unit is that it was bought by a recording studio a while ago and I was reassured that all was running perfect except for the fact that the power button does not stay in the on position... and an elastic band is used to keep the button suppressed and the unit on.

Problem: The unit frequently "cuts out". Meaning that at frequent random intervals the unit will either not process any sound or will have a significant delay accompanied by static/distortion. This happens regardless of whether it is a drum or cymbal that is triggered.

Ask: Any and all suggestions/advice are greatly appreciated.

Thanks in advance
Chris
------------------------