TemplarB

Members
  • Content count

    19
  • Joined

  • Last visited

  • Days Won

    1

TemplarB last won the day on November 6 2017

TemplarB had the most liked content!

Community Reputation

3 Neutral

About TemplarB

  • Rank
    Newbie

Recent Profile Visitors

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

  1. TemplarB

    Video stopped working

    The issue was solved. I used the archive collection mentioned in the post above and used pre-least version, i.e. 2.4.1-1554 and checkrd that it works on several files. works ok on PC and android, android app wasn't changed
  2. TemplarB

    Video stopped working

    Thanks a lot, @Dfds!
  3. TemplarB

    Video stopped working

    I use 2.4.2-1561 is there any way to downgrade?
  4. TemplarB

    Video stopped working

    In mid-July was an update to Video station and shortly after Video Station became unable to play video. It looks the same but when you attempt to play the file, usually you get "loading ring" on the screen and no play. This happens with files that were earlier played and which still can be played by other means. However, not all 100% don't work, there are still files that play normally (just a few). the problem persists in personal computer, different androids and iOS devices (via DS Video app). I asked by friend, who also has the server like mine, and on his server videos also don't play. I use baremetal HP Microserver Gen8 with Jun's loader v1.02b - DS3617xs and DSM 6.1.7-15284 Update 2
  5. TemplarB

    DSM 6.1.6-15266 Update 1

    - Outcome of the update: SUCCESSFUL - DSM version prior update: DSM 6.1.6-15266 - Loader version and model: JUN'S LOADER v1.02b - DS3617xs - Using custom extra.lzma: NO - Installation type: BAREMETAL - HPE Proliant MicroServer Gen8 - Additional comments: NO REBOOT REQUIRED
  6. TemplarB

    HP Gen 8 problems with ‘System health’ etc

    I had another system failure, this time GUI was out and, what was worse, the volume1 showed no directories in shh, so I haven’t been able to access my archive of usr/lib with correct files. Here are the steps what to do to restore the system Get PUTTY or other program to get to SHH Log in in SHH Run dmesg to see the loading log and errors Get a working copy of usr/lib either from someone with working DSM or have your ow archive. To make the archive use Run sudo zip -r9 /volume1/lib9.zip /usr/lib/ in PUTTY on working DSM. The path may differ Run sudo diff --brief -r /usr/lib/ /volume1/usr/lib/ | grep ' differ' You’ll get a list of bad files like: Files /usr/lib/libsynoshare.so.6 and /volume1/music/usr/lib/libsynoshare.so.6 differ Go to lib by running cd /usr/lib Rename bad file so (you’ll be asked for password again): sudo mv libsynoshare.so.6 ~libsynoshare.so.6 Replace it with good copy: sudo cp /volume1/usr/lib/libsynoshare.so.6 . (note the dot at the end) Set right as needed: sudo chmod 644 libsynoshare.so.6 Reboot: sudo reboot I hope it will help you as it helped me!
  7. Synology updated Transmission to 2.93, so this vulnerability is closed
  8. It is reported that pre-2.92 version Transmission has a serious vulnerability: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-5702 Current version of Download station uses 2.84 as its base. Is there a way to update Transmission and still run Download station? Or only shift to Docker's transmission will do?
  9. TemplarB

    DSM 6.1.5-15254 Update 1

    - Outcome of the update: SUCCESSFUL - DSM version prior update: DSM 6.1.5-15254 - Loader version and model: Jun's Loader v1.02b - DS3617xs - Installation type: Baremetal (HPE Microserver Gen8) - Additional comments: No reboot required
  10. TemplarB

    DSM 6.1.5-15254

    - Outcome of the update: SUCCESSFUL - DSM version prior update: DSM 6.1.4 15217 Update 5 - Loader version and model: Jun's Loader v1.02b - DS3617xs - Installation type: Baremetal (HPE Gen8) - Additional comments: Requires reboot
  11. TemplarB

    DSM 6.1.4-15217 Update 5

    - Outcome of the update: SUCCESSFUL - DSM version prior update: DSM 6.1.4 15217 Update 3 - Loader version and model: Jun's Loader v1.02b - DS3617xs - Installation type: Baremetal (HPE Proliant MicroServer Gen8) - Additional comments: Requires reboot
  12. TemplarB

    DSM 6.1.4 - 15217

    HP ProLiant MicroServer Gen8 DS3617xs Jun's Mod V1.02b baremetal update ok
  13. TemplarB

    HP Gen 8 problems with ‘System health’ etc

    Problem solved! Ok, what happened and what people should try. Because while I had problems described in the first post, the system kinda worked, so I planned to migrate it on weekend. Thus on Friday I got a warning from the Security Advisor that DSM system files have incorrect hash values, more precisely, libsynostoragemgmt.so The file had the same size and date as in other, perfectly working server, namely: However, when I replaced it with a version from the working server, the system was able to reboot normally (previously only hard reboot helped) and is ok ever since. So, if you have a similar problem 1. Scan your system with the Security Advisor 2. If there are wrong hashes, replace the mentioned files, check that their attributes are correct 3. reboot
  14. TemplarB

    Baremetal reinstall option in 1.02b

    After I experienced some problems with my HP Gen8 baremetal Jun 1.02b installation of ds3617 [which described here - https://xpenology.com/forum/topic/9276-hp-gen-8-problems-with-‘system-health’-etc/?tab=comments] I plan to try to repair the situation by migration. On this site I read that people migrated successfully e.g. from 3617 to 3615, but I want to know whether it is possible to migrate [and safely transfer all data] from 3617 to 3617 by using reinstall option in GRUB loading menu that is present in the current installation. Or will this destroy/wipe/corrupt the data? Or the only way to have 3617 at the end is to migrate twice?
  15. TemplarB

    HP Gen 8 problems with ‘System health’ etc

    Update on the topic. As was mentioned above, similar problem occurred more than once after critical updates on HP Gen8 [supposedly with ds3617, but maybe 3615 too]. I have a pet theory of mine that the problem is not caused by a specific update but by server’s consequent reboot: people most likely reboot their servers rarely, thus while updates that led to the failure are different (it was 4, 5, 7 and 8 according to the forum history and it happened only for some, not all) the reboot is the common thing. Possibly that an update changes some config files or the like, I’m too much not a tech person to see the exact reason. However, I assume that the problem starts when the system decides after reboot to autodet RAID arrays. According to linux manuals this is an old feature that shouldn’t be used. It can detect only 0.9 superblock, but I have 1.2 superblock according to this: cat cat /proc/mdstat Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] [raidF1] md2 : active raid5 sda3[0] sdd3[3] sdc3[2] sdb3[1] 4380946368 blocks super 1.2 level 5, 64k chunk, algorithm 2 [4/4] [UUUU] md1 : active raid1 sda2[0] sdb2[1] sdc2[2] sdd2[3] 2097088 blocks [12/4] [UUUU________] md0 : active raid1 sda1[0] sdb1[1] sdc1[2] sdd1[3] 2490176 blocks [12/4] [UUUU________] unused devices: <none> Hide so, it is not surprising it says in log sda3 does not have a valid v0.90 superblock, not importing! Any thoughts?