Jump to content
XPEnology Community


Transition Member
  • Posts

  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

princerock's Achievements


Newbie (1/7)



  1. First thanks for the work! I'm trying to apply the patch and as far as I can tell it's successful: ash-4.3# ./patch.sh -p Detected DSM version: 6.2 23739-2 Patch for DSM Version (6.2 23739-2) AVAILABLE! Available binaries to patch/restore: 1) /usr/syno/bin/synocodectool 2) Quit Please choose which binary you want to patch/restore:1 Restored synocodectool and valid backup detected (DSM 6.1.4-15217-0_6.2-23739-2) . Patching... Patched successfully Creating spoofed activation.conf.. Spoofed activation.conf created successfully However, when I upload a video to Photo Station the transcode still fails: 2021-03-19T11:31:54-05:00 DiskStation synoflvconv: synoflvconv.cpp:617 Failed to convert video [/volume2/photo/2021/test1/2020_1025_162528_068.MP4] to h.264 mp4. Any idea what I might be missing here to make Photo Station conversion work?
  2. Looks like that is the case even if you don't plan to use quick connect. NeoID has done some research on this. I'm just not sure what a valid SN is, and if the tool checks the MAC too. The error message only complains about the SN, but who knows what it really checks? I'm wondering if this is a signal that Synology has started to add more checks to their code so that they can limit what non-authorized system (like Xpenology) can do. I didn't have this problem in 5.2.
  3. Using Jun's loader 1.02a with 6.1.1update4. Everything was working fine until this weekend when I found a problem. I uploaded a couple of video's to photo station and noticed the system log says video conversion failed. Opened the log and found the following messages: synocodectool: G1Licence.cpp:79 Licence not Success,error msg "SN format is wrong." synocodectool: SYNOCodecPatentG1.cpp:236 ValidateG1Licence failed synoflvconv: synoflvconv.cpp:575 Failed to convert video [/volume1/photo/test/IMG_4444.MOV] to h.264 mp4. So looks like synocodectool is checking SN before doing any video conversion. And somehow the SN format is wrong. I'm using the SN generated from "the new generator" (https://xpenology.github.io/serial_generator/serial_generator_new.html), which has 13 digits (1*30LWN******). I've tried a couple others but got the same error. Then I tried the old format (10 digits) and still got the same error. Since when did DSM begin to check SN when it does video conversion? Has anyone seen a similar issue? I'm always under the impression that you only need an SN/MAC for Quick connect, which I don't really need. If DSM begins to enforce SN checking for vidoe conversion, that would have a bigger impact on Xpenology. If anyone knows how to get around this, please let me know. Thank you!
  4. OzTechGeek could you please elaborate? I think I'm having the same issue, but I'm using KVM hypervisor. Health Info shows not available but I'm able to get temperature info. With 5.2 there was no issue. I'm thinking if it's caused by the additional virtual disk (loaded .img), so I'm trying to find a way to convert img to iso. I tried using SATA driver and IDE for the virtual disk but they don't make any difference. Thanks!
  5. Does anyone have a iso version of the loader? I'm trying to convert the .img to .iso but haven't figured out a way to do that. Most tools would fail because the *.img has multiple partitions. I tried img to iso, OSFmount and haven't got a bootable iso. If anyone knows how to do this please let me know. The reason I want a iso is because I'm trying to use it in KVM.
  6. OK after some debug I believe it's most likely caused by this update: 5.2-5644.4 (23/12/2015) Disable old crappy realtek r8169 module, update r8101 / r8168 / r8169 drivers If I use 5.2-5644.1 there is no such a problem. Both 5.2-5644.4 and 5.2-5644.5 have this problem. My NIC is 8111G. It looks like when this happens something messed up in the NIC. I couldn't access it unless I do a full power cycle on the machine. Reboot doesn't help. Does anyone else see an issue with the NIC after the update? Is there a way to contact sancome and/or the team about this? I would like to find a way to bring back the "old crappy" module back if possible, as that works for my card! Thanks.
  7. I have been running Xpenology in a VM. The host is Arch Linux. I'm passing a nic to the VM and it's been working fine. Yesterday I was trying to update the DSM from 5592.4 to 5644. I used the latest XPEnoboot but somehow I couldn't connect to it (that means I didn't install or upgrade anything). So I went back to 5592 but this time I still cannot connect to the VM! When I log in through local VNC I saw the following in dmesg: [14.959510] r8169 0000:00.08.0 eth0: unable to load firmware patch rtl_nic/rt8168g-2.fw (-2) [15.164073] r8169 0000:00.08.0 eth0: rtl_phy_reset_cond == 1 (loop: 100 delay: 1). [15.166654] r8169 0000:00.08.0 eth0: link down Does anyone know why all of a sudden the firmware cannot be loaded? Can I install it? I did updated some packages on the host (arch linux). Not sure if that could cause this. But again everything was working before I tried the update. Many thanks in advance.
  • Create New...